CRC-32 Checksum Calculator

What is a CRC checksum?

A Cyclic Redundancy Check (CRC) is an error-detection algorithm that maps an input of any size to a short, fixed-length value called a checksum or digest. It is deterministic — the same input always produces the same output — and highly sensitive to accidental bit errors, making it ideal for verifying data integrity in storage and network transmission.

Are CRC checksums safe for cryptographic use?

No. CRC is an error-detection algorithm, not a cryptographic hash. It is not collision resistant and can be deliberately forged by an attacker — finding a second input that produces a given CRC is computationally trivial. For security-sensitive applications such as digital signatures or message authentication, use a purpose-built cryptographic hash like SHA-256 or BLAKE2.

How does CRCKit protect my data?

All checksum computation runs entirely inside your browser using the js-crc library by emn178. No text, no file content, and no checksum output is ever transmitted to any server. You can verify this by running the tool while offline — it works identically once the page has loaded.

What output formats are available?

Hex (lowercase hexadecimal) is the most common format used in tooling and documentation. HEX is the same in uppercase. Base64 encodes the raw bytes as a shorter string often used in HTTP headers and data URIs. Binary shows the individual bits, useful for educational purposes or low-level protocol work.

What is CRC-8?

CRC-8 produces an 8-bit (1-byte) checksum, shown as a 2-character hex string. Its compact output makes it the preferred choice for embedded systems, low-bandwidth sensors, and peripheral buses where even a single extra byte of overhead matters. Several CRC-8 variants exist, each standardised for a specific protocol, differing in polynomial, initial value, and whether input bits are reflected before processing.

What does CRC-8 detect?

An 8-bit CRC is guaranteed to detect all single and double-bit errors in messages up to 119 bits, all odd numbers of bit errors, and all burst errors of length 8 or fewer. For typical short sensor payloads of a few bytes this covers the overwhelming majority of realistic corruption scenarios. For longer messages or adversarial environments, a wider CRC or a cryptographic MAC is more appropriate.

Variant comparison

Which CRC-8 variant should I use?

Follow your hardware or protocol specification. If you are working with a Dallas/Maxim 1-Wire device, CRC-8 (1-Wire) is mandatory — its reflected polynomial is baked into the silicon. If you are implementing a DVB-S2 receiver or modulator, CRC-8 (DVB-S2) is required by the standard. For SMBus or general-purpose use, CRC-8 (SMBus) (0x07) is the most broadly supported choice.

Why are there so many CRC-16 variants?

All CRC-16 variants produce a 16-bit (2-byte) checksum but differ in four parameters: the generator polynomial, the initial register value, whether input and output bits are reflected, and a final XOR value. Each combination was standardised by a different industry body for a specific protocol, which is why a single bit-width has accumulated so many named forms over the decades.

Variant comparison

Which CRC-16 variant should I use?

Follow your protocol specification exactly — mixing variants produces incompatible checksums even though they share the same bit width. If you are choosing freely (e.g. for a custom framing layer), CRC-16 (Modbus) is a solid default: its non-zero initial value catches leading-zero errors that the plain CRC-16 misses. Use CRC-16 (USB) when implementing USB device firmware, and CRC-16 (DNP) for any DNP3 or IEC 60870-compatible SCADA integration.

What is CRC-24?

CRC-24 produces a 24-bit (3-byte) checksum, shown as a 6-character hex string. Its 24-bit width offers a collision probability of roughly one in 16 million — a substantial improvement over 16-bit CRCs while remaining smaller than CRC-32. Several incompatible CRC-24 variants exist, each standardised by a different body for a specific protocol, differing in polynomial, initial value, input reflection, and final XOR.

Variant comparison

Which CRC-24 variant should I use?

Follow your protocol specification exactly — the three variants use entirely different polynomials and are mutually incompatible. CRC-24 (BLE) is mandatory for Bluetooth Low Energy link-layer implementations; note that the init value is fixed for advertising packets but negotiated per-connection on data channels. CRC-24 (Intlkn) is required for Interlaken-compliant chip-to-chip serial hardware. CRC-24 (OpenPGP) is the correct choice for any PGP or GPG ASCII Armor interoperability. If you are choosing freely and need a 24-bit checksum, CRC-24 (OpenPGP) is the most widely implemented variant in existing software libraries.

What is CRC-32?

CRC-32 uses the polynomial 0x04C11DB7 in reflected form and produces a 32-bit (4-byte) checksum, typically shown as an 8-character hex string. It was standardised in IEEE 802.3 (Ethernet) and is embedded in Ethernet frames, ZIP archives, PNG images, and gzip streams. Its 32-bit width makes accidental collision probability roughly one in four billion, which is sufficient for most integrity-checking workloads.

Variant comparison

Which CRC-32 variant should I use?

CRC-32 is the right default for most new applications — it is universally supported and used in Ethernet, ZIP, PNG, and gzip. If you are working on storage systems, databases, or any context where hardware acceleration matters, prefer CRC-32C (Castagnoli): it uses a superior polynomial with better error-detection properties and is directly accelerated by the crc32 SSE4.2 instruction on x86 and equivalent instructions on ARM. CRC-32 (MPEG-2) and CRC-32 (BZIP2) are non-reflected variants required by their respective standards — only use them when the spec mandates it. CRC-32 (JamCRC) is a niche variant that omits the final XOR, making it useful for chaining partial checksums; it is otherwise interchangeable with standard CRC-32 in terms of error detection.

What is CRC-64?

CRC-64 produces a 64-bit (8-byte) checksum, shown as a 16-character hex string. Its much wider output space — roughly 18 quintillion possible values — makes accidental collisions vanishingly unlikely, so it is preferred for large-scale storage systems, databases, and high-throughput data pipelines where even a one-in-four-billion CRC-32 collision rate is unacceptable. Several incompatible CRC-64 variants exist because different standards bodies chose different polynomials for different contexts.

Variant comparison

Which CRC-64 variant should I use?

Use the variant your protocol or storage system mandates — mixing them produces silently wrong checksums. CRC-64 (ECMA) and CRC-64 (XZ) both use the ECMA polynomial but differ in bit reflection: ECMA processes data without reflection while XZ uses the reflected form, so they produce different outputs from the same input. CRC-64 (NVMe) and CRC-64 (Redis) share the Jones polynomial in reflected form; Redis sets its initial value and final XOR to zero for hash-table consistency. Reach for CRC-64 in place of CRC-32 when protecting large datasets — multi-gigabyte files, database tables, tape archives — where the one-in-four-billion collision probability of CRC-32 becomes a real operational risk over millions of objects. For individual files or network framing, CRC-32 is almost always sufficient.

What is CRC-82 (DARC)?

CRC-82 (DARC) uses an 82-bit polynomial defined in the DARC (Data Radio Channel) standard for broadcasting data over FM subcarriers — the multiplex data layer embedded in FM radio signals. It produces an 82-bit (rounded to 11 bytes, shown as a 21-character hex string) checksum. The unusual bit width was chosen specifically to match the frame structure of DARC data packets rather than any binary boundary, making it one of the few production CRCs with a non-power-of-two output width.

What is DARC used for?

DARC is a Japanese standard for FM multiplex broadcasting, used to deliver text data such as traffic information, news headlines, and programme guides over the 76 kHz subcarrier of FM radio. It is deployed in Japan's VICS traffic information system and similar FM data services. The 82-bit CRC protects short data frames where any undetected corruption could cause incorrect navigation instructions or garbled display text.

How does CRC-82 compare to other wide CRCs?

Its 82-bit width sits between the common 64-bit and 128-bit extremes, giving it a theoretical undetected-error probability of about one in 4.8 sextillion — stronger than CRC-64 but achieved at the cost of a non-standard output size that requires BigInt arithmetic in software implementations. Outside of DARC and its direct derivatives, you are unlikely to encounter CRC-82 in practice; CRC-64 covers most use cases that outgrow CRC-32.