CRC-32 Explained: The Checksum Algorithm Behind Data Integrity

CRC-32 is an error-detection checksum, not a hash for security. It takes a message and emits a fixed 32-bit number that changes with overwhelming probability if any bit of the message changes. It is fast and tiny, which is why it ships in zip, gzip, PNG and network frames — but its purpose is detecting accidental corruption, never intentional tampering.

The idea: polynomial division

Under the hood a CRC treats the message bits as the coefficients of a polynomial and divides that polynomial by a fixed 33-bit generator. All arithmetic happens in GF(2), meaning XOR instead of subtraction, so there is no borrowing. The remainder of that division is the checksum. For the standard CRC-32 the generator is 0x04C11DB7 (in its normal, non-reflected form).

Why the table contains 0xEDB88320

Bit-at-a-time division is simple but expensive. Real implementations process whole bytes at once using a precomputed 256-entry table. Most software also uses the reflected variant of the CRC-32 definition (bits and bytes processed least-significant-first), which is why you see 0xEDB88320 — the bit-reversed form of 0x04C11DB7 — in code like the Developer Calculator's table. Both notations describe the same catalogue standard; the reflected loop is just the common software form.

The four numbers that define it

The CRC register starts at 0xFFFFFFFF, not zero. After every byte it becomes table[(register XOR byte) & 0xFF] XOR (register >>> 8), and once all bytes are consumed the result is XORed with 0xFFFFFFFF again: (crc ^ 0xFFFFFFFF) >>> 0. Processing every byte costs four simple operations instead of eight bit-by-bit steps.

let crc = 0xffffffff;
for (const byte of bytes) {
  crc = CRC32_TABLE[(crc ^ byte) & 0xff] ^ (crc >>> 8);
}
return (crc ^ 0xffffffff) >>> 0;

Why init and final XOR exist

Starting the register at 0xFFFFFFFF and XORing the result at the end is a convention that makes the checksum sensitive to leading zero bytes. Without it, a message like 0x00…00 would always checksum to the same value regardless of length. The initial value also prevents short messages from being described by a trivial polynomial remainder.

Worked examples

CRC-32 vs real hashes

Try it

Open the Developer Calculator's CRC-32 tool, paste any text, and compare its 32-bit checksum against the examples above. For real hashes such as SHA-256, use the Hash Generator.