CRC naming collisions: same name, different checksum

A CRC's popular name usually describes its history or the standard it came from, not a strict, enforced parameter set. Different tools, chip vendors, and specifications have historically reused names like "CRC-16/CCITT" for more than one underlying model, so two implementations can both be correct and still disagree if they picked different models that happen to share a name.

This is a different problem from the mismatches covered in the CRC mismatch troubleshooting checklist, where two implementations of the same model disagree because of a bug. Here, both implementations can be completely correct — they are simply computing two different, equally legitimate CRC models that happen to share a nickname. The fix is to identify the exact model by its full parameter set, not by name, and confirm it against the standard check value.

"CRC-16/CCITT" is the clearest example. At least three catalogued models are commonly called some variant of that name, and all three share the 0x1021 polynomial — which turns out to be the only thing they agree on.

All three appear in vendor documentation labeled simply "CCITT," with no further qualifier, so the name alone never identifies which one is meant. The only way to know for certain is to compute the check value for ASCII 123456789 and compare it against the three below, or check the specification's own worked example.

CRC-16/ARC (aliases CRC-16/IBM, CRC-16/LHA) and CRC-16/MAXIM-DOW (alias CRC-16/MAXIM) share polynomial 0x8005, Init 0x0000, and reflect both input and output — every parameter that most naming schemes treat as the ones that matter. They differ in exactly one place: XorOut. CRC-16/ARC uses XorOut 0x0000 and produces check value 0xBB3D for 123456789; CRC-16/MAXIM-DOW uses XorOut 0xFFFF and produces check value 0x44C2.

Because only one field differs, a hand-written implementation that hardcodes an all-zero XorOut, or skips the final XOR step on the assumption that "reflected output means no final XOR," will silently compute ARC's result while claiming to implement MAXIM-DOW, or the reverse. The two names are not interchangeable despite describing what looks like the same checksum under different vendor branding.

The same pattern repeats one width up. CRC-32/ISO-HDLC — the CRC-32 behind ZIP, PNG, and Ethernet-adjacent tooling — and CRC-32/JAMCRC share polynomial 0x04C11DB7, Init 0xFFFFFFFF, and reflect both input and output. CRC-32/JAMCRC is, in effect, CRC-32/ISO-HDLC with the final XOR removed: ISO-HDLC applies XorOut 0xFFFFFFFF (check value 0xCBF43926), while JAMCRC applies no final XOR at all (check value 0x340BC6D9).

That makes JAMCRC easy to produce by accident: an implementation of the common CRC-32 that simply omits the final complement step is not a buggy CRC-32 — it is a correct implementation of a different, real, catalogued model. If a checksum consistently differs from an expected CRC-32/ISO-HDLC value by what looks like a bitwise NOT, JAMCRC is the first thing to check.

Not every alternate name signals a different model. CRC-16/UMTS is also documented as CRC-16/BUYPASS and CRC-16/VERIFONE across different specifications and payment-terminal vendor documentation, but all three names describe the exact same parameter set — polynomial 0x8005, Init 0x0000, no reflection, no final XOR, check value 0xFEE8 — so they are safe to treat as fully interchangeable. The same is true of CRC-16/ARC's own aliases, CRC-16/IBM and CRC-16/LHA: one model, several names for the same history.

The distinguishing test is always the same regardless of which side of this a name falls on: compute the check value for ASCII 123456789 and compare it to the model's published value. If two differently named calculators agree on that value, treat them as the same model no matter how different their documentation reads; if two identically or similarly named calculators disagree on it, they are different models that happen to share a name, and the full parameter table — not the name — is the source of truth.

CRC-16/IBM-SDLC — also known as CRC-16/X-25 and, informally, CRC-16/ISO-HDLC — is the frame check sequence defined in ISO/IEC 3309 for HDLC, and it is this same field that ITU-T Recommendation X.25 and V.42 reuse for the equivalent 16-bit checksum. The other two models in this guide's CCITT trio are not defined by a single formal standards body in the same way; their names come from historical toolchain usage rather than one document. Every parameter and check value cited above is cross-referenced against the Catalogue of CRC Algorithms (reveng.sourceforge.io).