CRC32 Checksum Calculator

The CRC-32 (Cyclic Redundancy Check, 32-bit) is a fast checksum used to detect accidental data corruption. This tool encodes your text as UTF-8 and computes the IEEE 802.3 CRC-32 over those bytes, the same checksum used by zlib, gzip, PNG, ZIP, and Ethernet frames.

How it works

CRC-32 treats the input bytes as the coefficients of a large binary polynomial and divides it (modulo 2) by a fixed generator polynomial, keeping the remainder. The implementation here uses the table-driven reflected method:

crc = 0xFFFFFFFF
for each byte b:
    crc = TABLE[(crc ^ b) & 0xFF] ^ (crc >>> 8)
result = crc ^ 0xFFFFFFFF

TABLE is a 256-entry lookup precomputed from the reflected polynomial 0xEDB88320. The initial value 0xFFFFFFFF and the final XOR with 0xFFFFFFFF are part of the standard IEEE variant, which is why an empty input yields 00000000 and the classic test phrase yields a well-known value.

Where CRC-32 is actually used

Understanding where the IEEE 802.3 CRC-32 appears helps you confirm you are comparing the right variant:

• gzip and zlib — both use this CRC-32 as the standard integrity check. When you call zlib.crc32() in Python or Node.js, you get this variant.
• PNG image files — each PNG chunk has a 4-byte CRC-32 at the end using this polynomial. A corrupted PNG chunk produces a CRC mismatch.
• ZIP archives — the local file header in a ZIP file stores a CRC-32 of the uncompressed data using this polynomial.
• Ethernet frames — IEEE 802.3 defined this variant for network frame error detection, which is where it gets the “IEEE 802.3” designation.
• Java’s java.util.zip.CRC32 — implements this variant.
• PostgreSQL’s crc32() function — also this variant.

CRC-32 variants and why they produce different results

If you compare this tool’s output with another CRC calculator and get a different result, the most likely cause is a different polynomial or parameter set:

The encoding also matters: this tool processes UTF-8 bytes. If another tool processes the same visible text as UTF-16 or ISO-8859-1, it will produce a different checksum for any non-ASCII characters.

What CRC-32 cannot do

CRC-32 is designed for accidental error detection, not security. It has two important limitations:

1. Collisions are easy to engineer. Anyone who can modify data in transit can craft a modified message with the same CRC-32. This makes it unsuitable for any security purpose — do not use it to verify authenticity or tamper resistance.
2. Multiple errors can cancel out. CRC-32 is very good at detecting single-burst errors (a common failure mode in storage and transmission) but can miss some patterns of multiple independent bit errors that happen to produce the same remainder.

For cryptographic integrity, use SHA-256 or BLAKE3. CRC-32 is for fast data-corruption detection in controlled environments where adversarial manipulation is not a concern.

Tips and notes

• The well-known test vector "The quick brown fox jumps over the lazy dog" produces the CRC-32 414fa339.
• An empty input produces 00000000 because of the initial value and final XOR convention.
• If you need CRC-32C (used by iSCSI, ext4, and many modern storage systems), note it uses a different polynomial and will not match values from this tool.
• Encoding matters: the same visible string in UTF-8 versus UTF-16 produces different bytes and a different checksum.