CRC32 Calculator

You’re building a file sync tool and need a fast way to detect whether a file has changed — not a cryptographic proof, just a quick “same or different” check. SHA-256 works but is overkill for this purpose and slower than necessary. Or you’re implementing a network protocol that requires CRC32 error detection (PNG, ZIP, Ethernet frames all use it). Or you’re debugging a corrupt ZIP file and need to verify the CRC32 values stored in the file headers match the actual content.

Why This Tool (Not a Library or Command Line)

Most CRC32 implementations require installing a library (crc-32 in npm, binascii.crc32 in Python) or writing a script. If you just need to check one value quickly — compare it against a specification, verify a file header, or debug a protocol implementation — this tool gives you the answer in seconds. It runs entirely in your browser with no server processing.

What Is CRC32?

CRC32 (Cyclic Redundancy Check, 32-bit) is an error-detecting code that produces a 32-bit (4-byte) checksum from any input data. It is based on polynomial division in GF(2) — the binary Galois field — using the generator polynomial 0x04C11DB7 (IEEE 802.3 standard, also known as CRC-32/ISO-HDLC).

CRC32 is not a cryptographic hash. It is designed for speed and error detection, not security:

• Fast: CRC32 can be computed at multi-gigabyte-per-second rates, especially with hardware acceleration (Intel’s CRC32 instruction)
• Deterministic: The same input always produces the same 32-bit output
• Not collision-resistant: It is trivial to find two inputs with the same CRC32 — there are only 2³² possible values
• Not one-way: The input can be reverse-engineered from the CRC and known constraints

How CRC32 Works

The CRC algorithm treats the input data as a long binary polynomial and divides it by a fixed generator polynomial. The remainder of this division is the CRC value.

Conceptually:

1. Append 32 zero bits to the input message
2. Divide by the generator polynomial 0x04C11DB7 using XOR-based polynomial long division
3. The 32-bit remainder is the CRC32 value
4. Apply bit reflection and final XOR (0xFFFFFFFF) per the standard

In practice, CRC32 is computed using a precomputed 256-entry lookup table for efficiency:

// CRC32 lookup table generation
function makeCRC32Table() {
  const table = new Uint32Array(256);
  for (let i = 0; i < 256; i++) {
    let crc = i;
    for (let j = 0; j < 8; j++) {
      crc = (crc & 1) ? (0xEDB88320 ^ (crc >>> 1)) : (crc >>> 1);
    }
    table[i] = crc;
  }
  return table;
}

// Computing CRC32
function crc32(data) {
  const table = makeCRC32Table();
  let crc = 0xFFFFFFFF;
  for (const byte of data) {
    crc = table[(crc ^ byte) & 0xFF] ^ (crc >>> 8);
  }
  return (crc ^ 0xFFFFFFFF) >>> 0;
}

import binascii

# CRC32 of a string
value = binascii.crc32(b"Hello, World!") & 0xFFFFFFFF
print(f"{value:08X}")  # EC4AC3D0

The IEEE 802.3 Polynomial

The standard CRC32 polynomial used by this tool is 0x04C11DB7, also written as x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1. In reflected (LSB-first) form, it becomes 0xEDB88320.

This polynomial is used by:

• Ethernet (IEEE 802.3) — every frame includes a 4-byte CRC32 for error detection
• ZIP and GZIP — file integrity verification
• PNG — chunk integrity verification
• MPEG-2 transport streams
• SATA — data link layer error detection

Other CRC32 variants exist (CRC-32C using Castagnoli polynomial 0x1EDC6F41, CRC-32Q), but the IEEE 802.3 polynomial is by far the most common.

Where CRC32 Is Used

File formats: ZIP, GZIP, PNG, and RAR all store CRC32 checksums to verify that file contents haven’t been corrupted during storage or transfer. When you see “CRC error” while extracting a ZIP file, it means the stored CRC32 doesn’t match the computed CRC32 of the decompressed data.

Network protocols: Ethernet frames include a 4-byte Frame Check Sequence (FCS) that is a CRC32 of the frame contents. The receiving NIC recomputes the CRC and drops frames that don’t match.

Databases: Some databases use CRC32 for hash partitioning — distributing rows across partitions based on CRC32(key) % num_partitions. It’s fast and provides reasonable distribution for non-adversarial inputs.

Caching and deduplication: CRC32 can serve as a quick pre-filter: if two files have different CRC32 values, they are definitely different. If they have the same CRC32, a full byte comparison (or stronger hash) is needed to confirm.

CRC32 vs Cryptographic Hashes

Rule of thumb: Use CRC32 for detecting accidental corruption. Use SHA-256 for detecting intentional tampering or for any security purpose.

Frequently Asked Questions

Is CRC32 secure? No. CRC32 is not a cryptographic function. It is trivial to construct two different inputs with the same CRC32 value, or to modify data while preserving the CRC32. Never use CRC32 for security purposes — use SHA-256 or stronger.

Why do ZIP files use CRC32 instead of SHA-256? When the ZIP format was designed in 1989, CPU power was limited and SHA-256 didn’t exist yet. CRC32 was fast and sufficient for detecting accidental corruption (bit flips, truncation). The format has been extended since, but CRC32 remains for backward compatibility.

What does “CRC mismatch” mean? It means the stored CRC32 value doesn’t match the CRC32 computed from the actual data. The file or data has been corrupted — usually during download, transfer, or storage. Re-download from the original source.