What Is CRC32?

CRC32 is a 32-bit checksum that tells you whether a block of data has been changed by accident. The sender computes four bytes from the data and attaches them; the receiver repeats the computation and compares. If the two values differ, the data was corrupted on the way.

It is the check behind Ethernet frames, ZIP and gzip archives, PNG images and countless device protocols — chosen because it is tiny, very fast, and extremely good at catching the kinds of errors that hardware actually produces. To compute one right now, use the CRC32 calculator.

The idea: a remainder after division

A simple checksum adds all the bytes together. That misses a lot: swap two bytes and the sum is unchanged. A CRC instead treats the whole message as one enormous binary number, divides it by a fixed constant — the generator polynomial — and keeps the remainder. Changing any bit changes the remainder in a way that depends on where the bit is, so reordered or shifted data is detected too.

The division is not ordinary arithmetic. It is done without carries, which means subtraction becomes XOR. That is what makes a CRC cheap in hardware: a shift register and a few XOR gates.

A worked example with a 3-bit CRC

The mechanics are identical at any width, so here is a small one. Message 1101, generator 1011 (a 3-bit CRC). Append three zero bits to the message, then repeatedly XOR the generator under the leftmost 1:

  1101000      message with 3 zeros appended
^ 1011
  -------
  0110000
^  1011
  -------
  0011100
^   1011
  -------
  0001010
^    1011
  -------
  0000001      remainder = 001

The CRC is 001 and the transmitted message is 1101001. The receiver divides those seven bits by the same generator; a remainder of zero means no error was detected. CRC32 does exactly this with a 33-bit generator and a 32-bit remainder.

The CRC32 parameters

The standard CRC-32 is defined by these values:

Written out, the polynomial is:

x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1

The extra steps around the plain division each solve a problem:

• Initial value 0xFFFFFFFF. With a zero start, leading zero bytes leave the register at zero, so 00 00 41 and 41 would have the same CRC. Starting from all ones makes leading zeros count.
• Final XOR 0xFFFFFFFF. The same protection for zeros appended at the end.
• Reflection. Serial hardware sends the least significant bit of each byte first. Reflecting makes the software result equal what the wire-level circuit computes.

CRC32 in code

The direct bit-by-bit version follows the definition:

uint32_t crc32(const uint8_t *data, size_t len)
{
    uint32_t crc = 0xFFFFFFFF;
    while (len--) {
        crc ^= *data++;
        for (int i = 0; i < 8; i++)
            crc = (crc & 1) ? (crc >> 1) ^ 0xEDB88320 : crc >> 1;
    }
    return crc ^ 0xFFFFFFFF;
}

The inner loop depends only on the low byte of the register, so its result can be precomputed for all 256 byte values. That gives the table-driven version used almost everywhere, about eight times faster:

static uint32_t table[256];

void crc32_init(void)
{
    for (uint32_t i = 0; i < 256; i++) {
        uint32_t c = i;
        for (int k = 0; k < 8; k++)
            c = (c & 1) ? (c >> 1) ^ 0xEDB88320 : c >> 1;
        table[i] = c;
    }
}

uint32_t crc32(const uint8_t *data, size_t len)
{
    uint32_t crc = 0xFFFFFFFF;
    while (len--)
        crc = table[(crc ^ *data++) & 0xFF] ^ (crc >> 8);
    return crc ^ 0xFFFFFFFF;
}

In practice you rarely write it yourself. Most languages ship the standard CRC-32:

Every one of these returns 0x3610A686 for hello. One trap: PHP's hash("crc32", …) without the b is the bzip2 variant and returns a different value.

What CRC32 detects — and what it does not

CRC32 is guaranteed to detect:

• any single flipped bit, in a message of any length;
• any burst error — a run of corrupted bits — up to 32 bits long;
• any two flipped bits, for messages up to the lengths used in practice (Ethernet frames, for instance).

For any other random corruption, the chance of it slipping through is 1 in 2³², about 1 in 4.3 billion.

What it does not give you:

• Protection against deliberate changes. CRC is linear, so an attacker can alter data and fix up the CRC without any effort. Use SHA-256 or an HMAC for that.
• Uniqueness. With only 2³² possible values, collisions between unrelated inputs are common once you have tens of thousands of items. Do not use CRC32 as a unique ID.
• Error correction. A CRC tells you that something is wrong, not what or where.

CRC32 compared with other checksums

For shorter checksums see the CRC16 calculator and the Modbus CRC calculator. To check a download, the file checksum calculator computes CRC32 and SHA-256 together.

CRC32 is often confused with its sibling CRC32C; the differences are laid out in CRC32 vs CRC32C. For checksums that are not CRCs at all — sums, XOR, Fletcher, Adler — use the checksum calculator, and for the 8-bit and 64-bit families the CRC8 calculator and CRC64 calculator.

Frequently asked questions