Checksum Calculator (CRC-32, Adler-32, byte sum)

Understanding the checksum calculator — concept and principle

A checksum is a short value computed from data so that accidental changes can be detected later: if the data is altered in storage or transmission, the recomputed checksum almost certainly differs. This calculator computes three checksums over the UTF-8 bytes of your text: CRC-32 (used in Ethernet, ZIP, gzip and PNG), Adler-32 (used in the zlib format) and a simple byte sum modulo 256.

How it is calculated

• CRC-32: start with the register 0xFFFFFFFF. For each byte, XOR it into the low bits, then eight times shift right by one and, if the bit shifted out was 1, XOR with 0xEDB88320 (the bit-reversed form of the generator polynomial 0x04C11DB7). Finally invert all bits.
• Adler-32: A starts at 1 and adds each byte; B adds the running value of A after each byte. Both are taken modulo 65521, the largest prime below 65,536. The checksum is B × 65536 + A.
• Byte sum mod 256: add all byte values and keep the remainder after dividing by 256.

The principle

CRC treats the message as a long polynomial with binary coefficients and computes the remainder of dividing it by a fixed generator polynomial, using XOR instead of subtraction. Because of this algebra, a 32-bit CRC detects every single-bit error and every burst of errors no longer than 32 bits. Adler-32 is faster to compute: A is a plain sum, and B weights each byte by its distance from the end, so swapping two bytes changes B even though A stays the same. A plain byte sum cannot see reordered bytes at all.

Worked example

1. Input: "The quick brown fox", 19 ASCII characters, so 19 UTF-8 bytes.
2. Byte sum: the codes add up to 1811; 1811 = 7 × 256 + 19, so the result is 19.
3. Adler-32: A = 1 + 1811 = 1812 = 0x0714. Summing A after every byte gives B = 17710 = 0x452E. The checksum is 452E0714.
4. CRC-32: running the bitwise procedure over the 19 bytes and inverting gives B74574DE.

How to read the result

Two copies of the data match only if their checksums match; any difference proves the data changed. Equal checksums strongly suggest, but do not prove, identical data: a 32-bit value has about 4.3 billion possibilities, so random collisions are rare for one comparison but become likely across very large collections.

Common mistakes

• Comparing a CRC-32 with one computed from a different encoding (UTF-16, or text with Windows line endings).
• Mixing CRC variants: CRC-32C (Castagnoli) and CRC-32/BZIP2 give different values for the same input.
• Using a checksum to protect against deliberate tampering.

Frequently asked questions

Is CRC-32 the same as a hash?

It is a hash in the loose sense, but it is linear and easy to forge, so it is not a cryptographic hash.

What CRC does an empty input give?

00000000 for CRC-32 and 00000001 for Adler-32, since A starts at 1 and B at 0.

Sources: IETF RFC 1952, GZIP file format specification (CRC-32) · IETF RFC 1950, ZLIB Compressed Data Format Specification (Adler-32) · W. W. Peterson and D. T. Brown, Cyclic Codes for Error Detection, Proceedings of the IRE, 1961