CRC-32 Hash Generator

Calculate a CRC-32 checksum locally.

What CRC-32 is

CRC-32 is the most widely deployed member of the cyclic redundancy check family, standardized in the early 1990s and baked into the file formats and network protocols most computers use every day. This tool computes the specific variant everyone means by default — sometimes called CRC-32/ISO-HDLC — using polynomial 0xEDB88320, an initial register of 0xFFFFFFFF, and a final XOR of 0xFFFFFFFF. It's the same algorithm used inside zlib, gzip, PNG image chunks, and every PKZIP/ZIP archive's per-file checksum.

What it's good for

CRC-32 gives a 32-bit fingerprint that reliably catches the kinds of errors that occur on real wires and disks — single and multi-bit flips, burst errors, and dropped bytes — using only a handful of CPU cycles per byte. That's why it's the checksum ZIP and gzip already compute for you automatically to confirm decompression succeeded. It was never designed to resist someone deliberately crafting a colliding payload, so it has no place protecting against intentional tampering.

How to use it

  1. Paste the text or data you want to checksum into the input box.
  2. Click Generate to compute the 8-digit hex CRC-32 locally in your browser.
  3. Compare the result against a checksum from a ZIP listing, a gzip header, or another tool's output.

Common questions

Which CRC-32 variant does this tool use?

The standard CRC-32 used by zlib, gzip, PNG, and PKZIP: polynomial 0xEDB88320, initial value 0xFFFFFFFF, final XOR 0xFFFFFFFF. It's the CRC-32 you'll encounter almost everywhere the name is used without qualification.

Is CRC-32 the same as a cryptographic hash?

No. CRC-32 catches accidental corruption, not deliberate tampering. With only 232 possible outputs and no resistance to intentional collision construction, it must never be relied on for security.

Why does my file's CRC-32 differ from what a tool reports?

This tool hashes the text you type as UTF-8. A file's CRC-32 (from 7-Zip, gzip, or PNG metadata) is computed over the file's raw bytes, which will differ from a UTF-8 re-encoding whenever the source uses a different encoding or contains binary data.

CRC-32 vs MD5 — which should I use for file integrity?

CRC-32 is fine for catching accidental corruption in archives and transfers, and it's what ZIP and gzip already embed. To confirm a file matches a publisher's checksum against tampering, prefer SHA-256 instead.