CRC Checksum Calculator

Overview

Computes two checksums over your text at once: CRC-32 and Adler-32, each shown as an 8-digit uppercase hex value. Input is encoded to UTF-8 bytes first, so results match what a server or firmware would compute over the same bytes. Both values appear live as you type, and clicking either result copies it.

How It Works

Paste or type text into the input area. Two cards appear below: CRC-32 and Adler-32, each with the checksum in uppercase hex, padded to eight digits. Values recompute on every keystroke because the algorithms are cheap. Click a card to copy its hex string. Nothing is shown until there is at least one byte to sum.

Step-by-Step Usage Guide

1. Type or paste the text whose checksum you need.
2. Read the CRC-32 value from the first card, in uppercase hex.
3. Read the Adler-32 value from the second card.
4. Click either card to copy the hex string for use in a test fixture or protocol message.

Technical Specifications & Standards

The CRC-32 here is the de facto standard used by zlib, gzip, PNG and Ethernet: the reflected polynomial 0xEDB88320, initialized to 0xFFFFFFFF, processing each byte through eight shift-and-xor rounds, and finishing with a final exclusive-or of 0xFFFFFFFF. It is a cyclic redundancy check, meaning it is the remainder of polynomial division of the message by a fixed generator, which gives it strong burst-error detection: all single-bit and double-bit errors, and any burst shorter than 32 bits, are guaranteed to be caught. Adler-32, invented by Mark Adler for zlib, is much simpler: two running 16-bit sums modulo 65521, where A starts at 1 and accumulates bytes and B accumulates the running A values; the checksum is B shifted left 16 bits, then A. It is faster in software but detects fewer error patterns, and its weakness on short messages is why some protocols restrict it to longer payloads. One honest scoping note: the tool's catalog entry mentions CRC-8, CRC-16 and CRC-32C, but the implementation computes exactly CRC-32 and Adler-32; if your protocol needs those other widths, this page cannot produce them. Text is converted with the UTF-8 encoder, so a non-ASCII character contributes multiple bytes and the checksums match byte-oriented tools, not character-counting ones.

Targeted Use Cases

• Verifying a payload checksum in a binary protocol test before sending it from a client.
• Reproducing a CRC-32 from a zip, gzip or PNG file for a debugging session.
• Generating Adler-32 values for zlib stream fixtures.
• Teaching the difference between polynomial CRCs and additive checksums with live numbers.

Notes & Gotchas

• Compare against tools that checksum bytes, not characters, especially with non-ASCII input.
• Do not use either checksum for security; both are trivially forgeable and not keyed.
• Use CRC-32 for stronger burst-error detection and Adler-32 only where a protocol mandates it, such as zlib.
• Remember the exact parameters matter: this is the standard reflected CRC-32 with init and final xor of FFFFFFFF, not one of the many non-standard variants.

Frequently Asked Questions