Lines use the form “ALGORITHM value” followed by an indented parameter line, so a copy-pasted result always says which parameter set produced it.
CRC — cyclic redundancy check, explained from scratch
In one sentence: a CRC treats your data as one gigantic binary number, divides it by a fixed “generator” number using XOR instead of subtraction, and reports the remainder — a compact fingerprint that changes wildly when even one bit of the input flips, which is why everything from PNG files to Modbus wires carries one.
What a CRC actually is
The division picture. Line up your bytes as one long binary number. Pick a divisor — the polynomial, e.g. 0x04C11DB7 for CRC-32. Perform binary long division where “subtraction” is the XOR operation: whenever the leading bit of the running remainder is 1, XOR in the divisor, shift left, repeat. After the whole message has gone through, whatever is left in the register is the CRC. No keys, no tables in the definition — just division with a remainder.
The five parameters. Two systems can both say “CRC-32” and still disagree, because the name alone fixes nothing. The full recipe needs five values: poly (the divisor), init (what the register starts as — all-zeros lets leading zero bytes vanish, all-ones does not), refin/refout (whether each input byte — and the final register — is bit-reversed, a legacy of serial hardware that sent bits least-significant-first), and xorout (a final XOR mask so a run of trailing zeros still changes the answer). This page prints all five next to every result for exactly that reason.
Why it detects errors. A well-chosen divisor makes the remainder of a message and the remainder of the same message with a few flipped bits differ with overwhelming probability: a good CRC-32 catches all 1-bit and 2-bit errors, all odd numbers of bit errors, and every burst of up to 32 consecutive corrupted bits — guaranteed, not probabilistically. That guarantee is about accidental corruption, and it is what makes CRCs the right tool for noisy wires and flaky disks.
What a CRC is not
Not a cryptographic hash. There is no secret and no one-wayness: anyone who knows the parameters can forge a message with any CRC they like, in milliseconds, by appending four correcting bytes. A CRC detects accidents, never adversaries. For downloads you verify against strangers, signatures matter — see the Hash Generator (MD5/SHA/BLAKE2) instead. That page also explains why MD5 and SHA-1 are retired for hostile settings while SHA-256 stands.
Not an error-correcting code. A CRC tells you that something changed, not what changed. Repairing errors on the fly is the job of codes like Reed–Solomon or Hamming, which deliberately store redundant structure a decoder can invert.
Not compression or encryption. The remainder is a few bytes regardless of input size, and from it you cannot recover the input — but unlike a cryptographic hash, that is merely because information was discarded, not because inversion is hard.
The families on this page
The CRC-32 quadruplets. Four of this page’s entries share the poly 0x04C11DB7 and still produce different values: ISO-HDLC (reflected, init/xorout all-ones) is “the” CRC-32 of zlib, gzip, PNG and ZIP; BZIP2 is the same math unreflected; MPEG-2 is BZIP2 with no final XOR; POSIX starts from zero and is the base of the cksum command (which additionally appends the file length to the division, so cksum of a file and CRC-32/POSIX of the same bytes differ). CRC-32C (Castagnoli, poly 0x1EDC6F41) is the fifth sibling: a different poly chosen for better error-detection performance, and the one modern x86 and ARM CPUs can compute at memory speed with one instruction.
The CRC-64 quartet. XZ uses the ECMA-182 polynomial in reflected form with all-ones init and xorout; ECMA-182 itself is the unreflected zero-init original from the DLT-1 tape standard; GO-ISO is Go’s crc64.ISO, a tiny poly 0x1B, still reflected; REDIS uses a poly picked for good avalanche in hash-slot assignment. Sixty-four bits is the size where CRCs start being used as hash functions (bucketing) rather than pure checksums.
Adler-32 is the outsider: it is not a division at all. It sums the bytes (A, starting at 1) and sums those sums (B), both modulo 65521, and concatenates the two 16-bit sums. It is faster than CRC-32 in software and zlib uses it for deflate streams — but for short inputs (under a few hundred bytes) the sum carries too little information, which is exactly why zlib switches back to CRC-32 for small blocks.
CRC-8 and CRC-16 survive where bytes are expensive: CRC-8/CCITT (poly 0x07) protects single header bytes in SMBus and cellular-radio protocols; CRC-16/CCITT-FALSE guards smart-card blocks; CRC-16/MODBUS is the checksum of every Modbus RTU frame on factory floors worldwide.
Where each one lives
| Parameter set | Found in |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), many archive formats |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, SSE4.2/ARMv8 hardware CRC32C instruction |
| CRC-32/BZIP2 | .bz2 archive stream |
| CRC-32/MPEG-2 | MPEG-2 transport streams |
| CRC-32/POSIX & cksum | POSIX cksum command output (cksum file.txt) |
| CRC-16/MODBUS | Modbus RTU frames (industrial PLCs, meters, inverters) |
| CRC-16/CCITT-FALSE | smart cards, X.25-adjacent links, some GPS protocols |
| CRC-8/CCITT | SMBus (PEC byte), cellular radio headers |
| CRC-64/XZ | .xz container integrity checks |
| CRC-64/ECMA-182 | ECMA-182 / DLT-1 tape standard |
| CRC-64/GO-ISO | Go standard library crc64.ISO |
| CRC-64/REDIS | Redis cluster hash-slot assignment |
| Adler-32 | zlib streams (deflate), other fast-checksum contexts |
The anchor table — check(“123456789”)
The CRC catalogue convention is to publish the result for the ASCII string 123456789 (9 bytes). Every value below is reproducible on this page: type 123456789 in the Text box, tick the algorithm, click Compute.
| Parameter set | Width | Check value (hex) |
|---|
| CRC-8/CCITT | 8 | 0xf4 |
| CRC-16/CCITT-FALSE | 16 | 0x29b1 |
| CRC-16/MODBUS | 16 | 0x4b37 |
| CRC-32/ISO-HDLC | 32 | 0xcbf43926 |
| CRC-32C | 32 | 0xe3069283 |
| CRC-32/BZIP2 | 32 | 0xfc891918 |
| CRC-32/MPEG-2 | 32 | 0x0376e6e7 |
| CRC-32/POSIX | 32 | 0x765e7680 |
| cksum (POSIX command) | 32 | 0x377a6011 |
| CRC-64/XZ | 64 | 0x995dc9bbdf1939fa |
| CRC-64/ECMA-182 | 64 | 0x6c40df5f0b497347 |
| CRC-64/GO-ISO | 64 | 0xb90956c775a41001 |
| CRC-64/REDIS | 64 | 0xe9c6d914c4b8d9ca |
| Adler-32 | 32 | 0x091e01de |
Sources: each value was cross-checked by an independent bitwise reference implementation and, where one exists, against the system library that ships the algorithm (zlib for CRC-32 and Adler-32; the Greg Cook CRC catalogue for the rest).
Common mistakes
- “CRC-32” without parameters. Between ISO-HDLC, BZIP2, MPEG-2, POSIX and CRC-32C, five different values circulate under the same name. Always record poly/init/refin/refout/xorout with the result — this page prints them for you.
- Comparing a file’s CRC-32 with its
cksum output. Different algorithms: cksum appends the length and uses a different init. The numbers will not match, and both are “right”.
- Trusting CRC against tampering. Forging a matching CRC is a textbook exercise (patch the last 4 bytes). Use a keyed MAC (HMAC) or a signature when the other side might be hostile.
- Expecting avalanche. A CRC is linear: related messages give related CRCs. Fine for noise, wrong for hashing — if you need bucketing, CRC-64 or a real hash is safer than CRC-32.
- Hex text vs bytes. The string
"123456789" (9 ASCII bytes, 31 32 33 34 35 36 37 38 39) and the number 0x123456789 are different inputs with different CRCs. Use the Hex bytes tab when your source data is truly binary.
FAQ
Why does my CRC-32 not match the one in the ZIP file? ZIP’s CRC-32 is ISO-HDLC over the uncompressed data. Make sure you hashed the same bytes (not the compressed stream), the same mode (Text vs Hex), and the same parameter set — the parameter line printed under each result is there to make that check instant.
Which is better, CRC-32C or CRC-32? For accidental-error detection both catch all bursts up to 32 bits; CRC-32C performs better on some error patterns and is the one with CPU instructions — effectively free at gigabit speeds. The reason CRC-32/ISO-HDLC survives is compatibility: thirty years of archives speak it.
Is CRC-64 stronger than CRC-32? It detects longer bursts (up to 64 bits) and collides far less when used for bucketing, but it is equally forgeable — width buys detection guarantees, not security.
Can a CRC be reversed to reveal the input? No — infinitely many inputs share a CRC. But unlike a cryptographic hash, an attacker can construct an input with any CRC they choose, which is the sense in which it is not one-way at all.
