CRC-64 guide: comparing all 7 variants
How the seven catalogued CRC-64 models differ, and which one applies to XZ, Redis, .cab files, NVMe, and general high-integrity use.
Why CRC-64 exists alongside CRC-32
A 32-bit CRC has a fixed collision probability regardless of message length, and for very large files or long-lived datasets that probability becomes large enough to matter. Doubling the CRC width to 64 bits reduces the chance of an undetected multi-bit error by roughly 2^32, which is why archive formats, storage protocols, and large-file tooling increasingly default to CRC-64.
The seven catalogued CRC-64 models
All seven variants are width-64 CRCs, but they differ in polynomial, initial value, reflection, and final XOR — treat each as a distinct model rather than a parameterization of "the" CRC-64.
- CRC-64/XZ — reflected; used by the .xz compression format and the Go crc64 ECMA table. A common default choice for new general-purpose use.
- CRC-64/GO-ISO — reflected ISO 3309 variant used by the Go standard library's crc64.ISO table.
- CRC-64/MS — reflected; used by Microsoft protocols including the .cab archive format.
- CRC-64/REDIS — reflected (also called CRC-64/JONES); used by Redis Cluster for key slot hashing and RDB file verification.
- CRC-64/NVME — reflected; used by the NVM Express storage specification for end-to-end data protection on modern NVMe SSDs.
- CRC-64/ECMA-182 — non-reflected; defined by ECMA-182 for high-integrity data interchange.
- CRC-64/WE — non-reflected; a Western Electric / Wireless Ethernet class variant.
Which one to pick
If a target format or protocol is named explicitly — .xz, Redis, .cab, NVMe — use that variant's preset rather than guessing; CRC-64 models are not interchangeable and a mismatched polynomial will silently fail every check.
CRC-64/NVME is worth calling out specifically: it is the model behind end-to-end protection on current-generation NVMe storage, so it is the one to reach for when validating checksums produced by NVMe drives, controllers, or storage stacks rather than defaulting to an older ECMA or ISO variant.
For new, protocol-agnostic use where no existing consumer dictates the model, CRC-64/XZ is a reasonable default: it is reflected (simpler to implement efficiently in software), widely deployed, and has a public reference implementation in most CRC libraries.
Primary sources
Where a variant is tied to a specific external format, that format's own specification is the authoritative source: the .xz File Format specification (published with the XZ Utils project) for CRC-64/XZ, ECMA-182 (Ecma International) for CRC-64/ECMA-182, and the NVM Express Base Specification for CRC-64/NVME. All seven variants' parameters — width, polynomial, initial value, reflection, and check value — are cross-referenced against the Catalogue of CRC Algorithms (reveng.sourceforge.io), the reference used throughout this site.
CRC-64 guide: comparing all 7 variants FAQ
When should I use CRC-64 instead of CRC-32?
Reach for CRC-64 when a 32-bit checksum's collision probability becomes a real risk — very large files, long-lived archives, or high-volume storage systems, where doubling the checksum width meaningfully reduces the chance of an undetected multi-bit error. If nothing external forces the choice, CRC-64/XZ is a reasonable general-purpose default.
Are the seven CRC-64 variants interchangeable?
No. Each of the seven catalogued CRC-64 models has its own polynomial, initial value, reflection, and final XOR, so a checksum computed with one variant will not validate against another even though both are called "CRC-64." Use the variant the target format specifies — XZ, GO-ISO, MS, REDIS, NVME, ECMA-182, or WE.
Apply this reference
Change CRC parameters and compare standard algorithm results using the browser-based calculator.