CRC-64 Checksum Generator

What is a CRC-64?

CRC-64 produces a 64-bit checksum from a block of data, using the same polynomial division as CRC-32 with twice the width. It is built to catch accidental damage: file corruption, storage faults, network errors, and truncated or incomplete data.

Choose a variant and check typed text or uploaded files. Output includes the value, hexadecimal text, and the raw digest.

Why the extra 32 bits

Collision probability. A 32-bit checksum has about four billion possible values, which sounds ample until you are checksumming millions of large objects, at which point coincidental matches stop being hypothetical. Widening to 64 bits pushes that far out of reach for any realistic data set.

The usual pattern is to compute a checksum before storing or transmitting something and again after retrieving it. Different values mean the data changed on the way. This is what package managers and archive formats are doing when they verify a download.

Are there alternatives?

CRC-32 is narrower, faster, and far more widely embedded in formats. Adler-32 is cheaper still. For content addressing or deduplication where you want a cryptographic guarantee, BLAKE3 is fast enough that the checksum families lose much of their advantage.

Fun facts and more info

The variants are mutually incompatible, and checksums from two of them will not match even over identical data. The default xz uses a reflected form of the ECMA polynomial, matches XZ compressed files, and is compatible with Go's crc64.ECMA. ECMA-182 is the original unreflected standard. Go-ISO matches Go's crc64.ISO. MS covers some Microsoft and Windows formats, NVMe is defined for storage devices, and Redis matches Redis checksum operations. WE is another unreflected ECMA-based variant with different initial and final values from ECMA-182.

When nothing imposes a requirement, use xz. And note that CRC-64 is for error detection only: it is not a cryptographic hash and must not be used for passwords, signatures, or security verification.