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 crc library by Alex Gorbatchev, loaded via the esm.sh CDN. 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-1?

CRC-1 is the simplest possible CRC: a single parity bit. It is computed by XOR-ing all the bits in the input together, yielding either 0 (even parity) or 1 (odd parity). As a CRC it uses the generator polynomial x + 1, and its output is a single bit — typically displayed as a single hex digit (0 or 1).

What errors does CRC-1 detect?

CRC-1 reliably detects any single-bit flip in the input. If two bits flip it cannot detect them, because the parity cancels out. It provides no error location information and no protection against burst errors. These limitations make it unsuitable for any application where data corruption is likely to affect more than one bit.

Where is CRC-1 used in practice?

Parity bits appear in serial communication hardware (UART, RS-232), ECC memory, and simple sensor protocols as a minimal sanity check before higher-level framing. CRC-1 is also used as the first worked example in coding-theory textbooks because its mathematics are trivial — making it easy to verify by hand. If you need meaningful error detection, step up to CRC-8 or higher.

What is CRC-8?

CRC-8 uses the polynomial 0x07 (represented as x⁸ + x² + x + 1) and 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 adding even two bytes of overhead matters.

What does CRC-8 detect?

CRC-8 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 everything else, plain CRC-8 (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.

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

How do the CRC-32 variants differ?

All three variants share the same polynomial (0x04C11DB7) and initial value (0xFFFFFFFF), but diverge in two parameters. Standard CRC-32 reflects both input bytes and the final output, then XORs the result with 0xFFFFFFFF — the form used in Ethernet, ZIP, PNG, and gzip. CRC-32 (MPEG-2) removes the bit reflection entirely, which flips byte order in a way suited to the big-endian framing of MPEG-2 transport streams and DVB. CRC-32 (JamCRC) keeps the same reflected processing as standard CRC-32 but omits the final XOR, so its output is the bitwise complement of a standard CRC-32 result — a property exploited by some network equipment and the JAM file format when chaining partial checksums. Use standard CRC-32 unless a specific standard requires otherwise.