CRC64 Calculator

Calculate a 64-bit CRC for text, hex bytes or a file of any size. The default is CRC-64/XZ; the table below the calculator shows every CRC-64 variant for the same input, with the parameters that set them apart.

9 bytes

Text encodingLine endings

Algorithm

Width (bits)PolynomialInitial valueFinal XOR

Reflect inputReflect output

ResultCRC-64/XZ

Uppercase0x prefix

0x995DC9BBDF1939FA

Decimal: 11051210869376104954
Binary: 1001100101011101110010011011101111011111000110010011100111111010
Bytes, big-endian: 99 5D C9 BB DF 19 39 FA
Bytes, little-endian: FA 39 19 DF BB C9 5D 99

Check value for "123456789": 0x995DC9BBDF1939FA

Source code for this CRC

Generated for the parameters above. Bit-by-bit and table-free, so it is easy to port to a microcontroller.

#include <stddef.h>
#include <stdint.h>

uint64_t crc_64_xz(const uint8_t *data, size_t len)
{
    uint64_t crc = UINT64_C(0xFFFFFFFFFFFFFFFF);
    while (len--) {
        crc ^= *data++;
        for (int i = 0; i < 8; i++)
            crc = (crc & 1) ? (crc >> 1) ^ UINT64_C(0xC96C5795D7870F42) : crc >> 1;
    }
    return crc ^ UINT64_C(0xFFFFFFFFFFFFFFFF);
}

All CRC algorithms for this input

Click a row to load its parameters into the calculator.

Result	Poly	Init	RefIn	RefOut	XorOut	Check	Used in
0x6C40DF5F0B497347	0x42F0E1EBA9EA3693	0x0000000000000000	false	false	0x0000000000000000	0x6C40DF5F0B497347	DLT-1 tape cartridges
0x995DC9BBDF1939FA	0x42F0E1EBA9EA3693	0xFFFFFFFFFFFFFFFF	true	true	0xFFFFFFFFFFFFFFFF	0x995DC9BBDF1939FA	xz / LZMA2 containers
0xB90956C775A41001	0x000000000000001B	0xFFFFFFFFFFFFFFFF	true	true	0xFFFFFFFFFFFFFFFF	0xB90956C775A41001	ISO 3309, Go hash/crc64 ISO table
0x62EC59E3F1A4F00A	0x42F0E1EBA9EA3693	0xFFFFFFFFFFFFFFFF	false	false	0xFFFFFFFFFFFFFFFF	0x62EC59E3F1A4F00A	Wolfgang Ehrhardt library
0x75D4B74F024ECEEA	0x259C84CBA6426349	0xFFFFFFFFFFFFFFFF	true	true	0x0000000000000000	0x75D4B74F024ECEEA	Microsoft MS-FCIADS
0xE9C6D914C4B8D9CA	0xAD93D23594C935A9	0x0000000000000000	true	true	0x0000000000000000	0xE9C6D914C4B8D9CA	Redis RDB files
0xAE8B14860A799888	0xAD93D23594C93659	0xFFFFFFFFFFFFFFFF	true	true	0xFFFFFFFFFFFFFFFF	0xAE8B14860A799888	NVMe, Amazon S3 checksums

The CRC64 variants and their parameters

A 64-bit CRC is the usual choice once data gets large enough that a 1-in-4-billion miss rate is no longer comfortable: archive formats, storage systems, object stores. As with the shorter CRCs, the name alone does not identify the algorithm. The check value is the CRC of the ASCII string 123456789.

Variant	Polynomial	Init / XorOut	Reflected	Check	Used in
CRC-64/XZ	`42F0E1EBA9EA3693`	all ones / all ones	yes	`995DC9BBDF1939FA`	xz, 7-Zip, Go `crc64.ECMA`
CRC-64/ECMA-182	`42F0E1EBA9EA3693`	zero / zero	no	`6C40DF5F0B497347`	DLT-1 tape cartridges
CRC-64/NVME	`AD93D23594C93659`	all ones / all ones	yes	`AE8B14860A799888`	NVMe, Amazon S3
CRC-64/GO-ISO	`000000000000001B`	all ones / all ones	yes	`B90956C775A41001`	ISO 3309, Go `crc64.ISO`
CRC-64/REDIS	`AD93D23594C935A9`	zero / zero	yes	`E9C6D914C4B8D9CA`	Redis RDB files
CRC-64/MS	`259C84CBA6426349`	all ones / zero	yes	`75D4B74F024ECEEA`	Microsoft file formats

Reflected implementations store the polynomial bit-reversed. If your source code contains 0xC96C5795D7870F42, that is 0x42F0E1EBA9EA3693 reversed — the XZ variant. 0xD800000000000000 is the ISO polynomial reversed.

CRC64 in code

CRC-64/XZ, bit by bit, in C:

uint64_t crc64_xz(const uint8_t *data, size_t len)
{
    uint64_t crc = UINT64_C(0xFFFFFFFFFFFFFFFF);
    while (len--) {
        crc ^= *data++;
        for (int i = 0; i < 8; i++)
            crc = (crc & 1) ? (crc >> 1) ^ UINT64_C(0xC96C5795D7870F42)
                            : crc >> 1;
    }
    return crc ^ UINT64_C(0xFFFFFFFFFFFFFFFF);
}

The same in Go, using the standard library table:

table := crc64.MakeTable(crc64.ECMA)
sum := crc64.Checksum([]byte("123456789"), table) // 0x995dc9bbdf1939fa

Python has no CRC64 in its standard library; the generated Python under the calculator runs as is. In JavaScript a 64-bit value does not fit in a number, so the generated code uses BigInt.

Test vectors

Input	CRC-64/XZ	CRC-64/ECMA-182	CRC-64/NVME
`123456789`	`995DC9BBDF1939FA`	`6C40DF5F0B497347`	`AE8B14860A799888`
`hello`	`9B1EDAE5DBB937B1`	`40544A306137B6EC`	`3377857006524257`

When 64 bits is worth it

Very large objects. Every block you check is another chance for a 32-bit CRC to miss an error. Across petabytes of storage that adds up; 64 bits removes the concern.
Content fingerprints. As a fast, non-cryptographic fingerprint for change detection, 64 bits keeps accidental collisions rare into the billions of items.
Not for short frames. On a 20-byte packet, eight bytes of CRC is 40% overhead. Use the CRC16 calculator or CRC8 calculator for those, and the CRC32 calculator for general files and network frames.

To check a download against several algorithms at once, the file checksum calculator computes CRC-64/XZ and CRC-64/NVME alongside CRC32 and SHA-256.

Frequently asked questions

What is CRC64?

CRC64 is a cyclic redundancy check with a 64-bit result. It works exactly like CRC32 but with a 65-bit generator polynomial, which makes an undetected error about four billion times less likely. Several variants exist; the most common are CRC-64/XZ, CRC-64/ECMA-182 and CRC-64/NVME.

What is the difference between CRC-64/ECMA-182 and CRC-64/XZ?

They share the polynomial 0x42F0E1EBA9EA3693 but nothing else. ECMA-182 is not reflected and uses zero for the initial value and final XOR; its check value is 0x6C40DF5F0B497347. CRC-64/XZ is reflected and uses all ones for both; its check value is 0x995DC9BBDF1939FA. Most software that says "CRC-64 ECMA" today, including Go and xz, actually computes the XZ variant.

Which CRC64 does Amazon S3 use?

CRC-64/NVME: polynomial 0xAD93D23594C93659, reflected, initial value and final XOR all ones. S3 reports it Base64-encoded in the x-amz-checksum-crc64nvme header, so convert the hex result to Base64 before comparing.

Is CRC64 better than CRC32?

For detecting accidental corruption in large files, yes: with 64 bits the chance of a random error going unnoticed is about 1 in 18 quintillion, against 1 in 4.3 billion for CRC32. It costs four extra bytes and is slightly slower. Like every CRC it offers no protection against deliberate tampering — use SHA-256 for that.

Can CRC64 be used as a unique ID or hash key?

With care. Among randomly chosen inputs, a collision becomes likely (50%) at around five billion items, so it is adequate for deduplication hints and hash tables of moderate size. It is not safe where someone could craft colliding inputs on purpose.