Calculate CRC-64 checksums of text or files up to 2 GiB each with the XZ, ECMA-182, Go-ISO, MS, NVMe, Redis or WE variant.
Runs in your browser — your input is processed on this device and never uploaded.
Pasted text up to 100 MiB, read as UTF-8, or files up to 2 GiB each.
Results appear here.
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.
| Variant | Matches |
|---|---|
| XZ | XZ compressed files and Go's crc64.ECMA. A reflected form of the ECMA polynomial. |
| ECMA-182 | The original unreflected standard. |
| Go-ISO | Go's crc64.ISO. |
| MS | Some Microsoft and Windows formats. |
| NVMe | The checksum defined for NVMe storage devices. |
| Redis | Redis checksum operations. |
| WE | Another unreflected ECMA-based variant, with different initial and final values from ECMA-182. |
Every variant is 64 bits wide. The check value is the CRC of the nine ASCII bytes 123456789, the usual way to confirm that two implementations agree.1
| Variant | Poly | Init | Reflected | XorOut | Check |
|---|---|---|---|---|---|
| XZ | 0x42f0e1eba9ea3693 | 0xffffffffffffffff | Yes | 0xffffffffffffffff | 0x995dc9bbdf1939fa |
| ECMA-182 | 0x42f0e1eba9ea3693 | 0x0 | No | 0x0 | 0x6c40df5f0b497347 |
| Go-ISO | 0x1b | 0xffffffffffffffff | Yes | 0xffffffffffffffff | 0xb90956c775a41001 |
| MS | 0x259c84cba6426349 | 0xffffffffffffffff | Yes | 0x0 | 0x75d4b74f024eceea |
| NVMe | 0xad93d23594c93659 | 0xffffffffffffffff | Yes | 0xffffffffffffffff | 0xae8b14860a799888 |
| Redis | 0xad93d23594c935a9 | 0x0 | Yes | 0x0 | 0xe9c6d914c4b8d9ca |
| WE | 0x42f0e1eba9ea3693 | 0xffffffffffffffff | No | 0xffffffffffffffff | 0x62ec59e3f1a4f00a |
Reflected means both the input bytes and the final value are bit-reversed, the RefIn and RefOut flags in CRC catalogues.
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.
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.
The variants are mutually incompatible, and checksums from two of them will not match even over identical data. When nothing imposes a requirement, use XZ.
Warning
CRC-64 is for error detection only. It is not a cryptographic hash and must not be used for passwords, signatures, or security verification.
Greg Cook, Catalogue of parametrised CRC algorithms (CRC RevEng). ↩
Find similar tools by category or tag.