CRC32 Checksum Calculator

How CRC32 checksums work

CRC32 (Cyclic Redundancy Check 32-bit) treats input data as a binary polynomial and performs polynomial division in GF(2) arithmetic by a fixed 33-bit generator polynomial (0x04C11DB7). The 32-bit remainder of this division becomes the checksum. In practice, CRC32 is implemented using a precomputed lookup table of 256 values for byte-by-byte processing, making it extremely fast.

CRC32 is designed for error detection, not security. It can detect all single-bit errors, burst errors up to 32 bits, and most multi-bit errors, but it offers no collision resistance — an attacker can easily craft data that produces any desired CRC32 value. Use it for integrity checks against accidental corruption, not against intentional tampering.

Checksum types comparison

Different checksum algorithms trade off speed, output size, and security. CRC32 sits in the middle — fast but not cryptographically secure.

How to use CRC32 Calculator

What is CRC32?

CRC32 (Cyclic Redundancy Check 32-bit) is an error-detecting code that computes a 32-bit checksum from arbitrary data. It was invented by W. Wesley Peterson in 1961 and has become one of the most widely used error-detection mechanisms in computing. CRC32 is used in Ethernet frames, ZIP archives, PNG images, Gzip compressed files, and countless other protocols and file formats.

The algorithm treats the input data as a large binary polynomial and performs polynomial division by a fixed 33-bit generator polynomial. The remainder of this division — always 32 bits — is the CRC value. The division uses GF(2) arithmetic (XOR without carries), making it extremely fast to implement in both hardware and software.

How CRC works (polynomial division)

CRC operates on the principle of polynomial division in GF(2) arithmetic. The input data is treated as a binary polynomial where each bit is a coefficient. This polynomial is divided by a fixed generator polynomial (for CRC32: x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1). The remainder is the CRC checksum.

In practice, CRC32 is implemented using a lookup table of 256 precomputed values. Each byte of input is processed by XORing it with the current CRC register, using the result as an index into the table, and shifting. This table-driven approach processes data one byte at a time and is highly efficient — CRC32 can process hundreds of megabytes per second even in JavaScript.

CRC vs hash: speed vs security

The fundamental difference between CRC and cryptographic hashes is intent. CRC is designed for error detection — catching accidental changes to data during transmission or storage. It is extremely fast and hardware-optimized but provides no security guarantees. A CRC32 checksum has only 32 bits, meaning there are only 4 billion possible values — collisions are trivially easy to create intentionally.

Cryptographic hashes like SHA-256 are designed for security. They are intentionally slower (to resist brute-force attacks), produce larger outputs (256 bits), and are collision-resistant by design. Use CRC when you need to detect random corruption in network packets or storage media. Use SHA-256 when you need to verify that data hasn't been tampered with by an adversary.

Error detection capabilities

CRC32 can detect all single-bit errors, all two-bit errors (when the polynomial is chosen appropriately), all errors affecting an odd number of bits, and any burst error of length 32 bits or less. Burst errors longer than 32 bits have a detection probability of 1 - 2⁻³² (99.99999998%). This makes CRC32 highly effective for real-world error detection.

However, CRC32 is not a cryptographically secure checksum. Given a specific checksum, an attacker can construct data that produces the same CRC32 value. This is because CRC operations are linear in GF(2), meaning CRC(a XOR b) = CRC(a) XOR CRC(b). This linearity makes CRC completely unsuitable for any security application where an adversary might intentionally corrupt data.

Frequently asked questions