Hex CRC32 Calculator
Compute the CRC32 (CRC-32/ISO-HDLC) checksum used in ZIP archives, PNG images, and gzip — verified against the official test vector.
Built by
Swapnil SanghviFull-Stack Web Developer & WordPress Developer
Swapnil Sanghvi is a full-stack web and WordPress developer, UI designer, and full-time freelancer who builds and maintains Hex Calculator.
Further reading: Cyclic redundancy check — Wikipedia
How CRC32 Is Computed
CRC32 processes the input one byte at a time, updating a running 32-bit value using a precomputed lookup table derived from the CRC-32/ISO-HDLC generator polynomial (0xEDB88320). The running value starts at all 1s and is inverted again at the end — both details matter for matching the standard result exactly, which is why hand-verifying against a known test vector is the safest way to confirm an implementation is correct.
CRC32 Test Vector, Verified
CRC32("123456789") = 0xCBF43926
CRC32(0x313233343536373839) = 0xCBF43926
Input bytes: "123456789" (9 ASCII bytes) Run CRC-32/ISO-HDLC over all 9 bytes Result: 0xCBF43926 (the official check value)
| Step | Description | Result |
|---|---|---|
| Encode input as bytes | "123456789" -> 0x313233343536373839 (9 bytes) | 9 bytes |
| Run the CRC-32/ISO-HDLC algorithm | process each byte through the table-driven update | running 32-bit value |
| Finalize | invert the final value (XOR with 0xFFFFFFFF) | 0xCBF43926 |
0xCBF43926 is the standard published check value for CRC-32/ISO-HDLC — every correct implementation of this specific variant produces exactly this result for this exact input, which is why it's the standard way to sanity-check a CRC32 implementation.
Where CRC32 Actually Comes Up
Verifying a ZIP Entry Wasn't Corrupted
Every file inside a ZIP archive has a stored CRC32 — recomputing it over the extracted bytes and comparing to the stored value is exactly how archive tools detect a corrupted entry.
extracted bytes CRC32 == stored CRC32
Validating a PNG Chunk
Each chunk in a PNG file (IHDR, IDAT, and so on) ends with a CRC32 covering that chunk's type and data — decoders use it to detect a truncated or corrupted image file before attempting to render it.
chunk type + data -> CRC32 trailer
Sanity-Checking a Custom CRC32 Implementation
When implementing CRC32 in embedded C, a build script, or any language without a built-in, running the standard "123456789" test vector through your code and comparing against 0xCBF43926 is the fastest way to catch a bug.
CRC32("123456789") == 0xCBF43926
Why Use This Calculator Instead of Doing It by Hand
- Verified against the official CRC-32/ISO-HDLC check value before shipping
- Table-driven implementation computes instantly even on longer byte sequences
- Runs entirely in your browser — nothing you type gets sent anywhere
- Accepts hex byte input directly, matching how file bytes are usually represented
Limitations
- This is CRC-32/ISO-HDLC specifically — CRC-32C (Castagnoli), used by iSCSI and ext4, uses a different polynomial and will not match.
- Input is treated as raw hex bytes — an odd number of hex digits gets a leading zero nibble added first, since a byte needs two hex digits.
Frequently Asked Questions
Where is CRC32 actually used?
ZIP archives store a CRC32 per file entry to detect corruption; PNG images embed a CRC32 in every chunk; gzip appends one to the compressed stream. It's one of the most widely deployed error-detection codes in everyday file formats.
Why does my ZIP tool show a different CRC32 than a plain checksum of the file?
ZIP's CRC32 is computed over the uncompressed file bytes, using the specific CRC-32/ISO-HDLC polynomial — a generic "checksum" utility using a different algorithm (or a different CRC variant) will produce a different number even for the identical bytes.
How do I verify this calculator computes CRC32 correctly?
Enter 313233343536373839 (the hex bytes for the ASCII string "123456789") — the official CRC-32/ISO-HDLC check value for that exact input is 0xCBF43926, which this calculator reproduces exactly.
Does file size affect how CRC32 is computed?
No — CRC32 processes the input one byte at a time regardless of length, so it works identically on a single byte or a multi-megabyte file; only the amount of input you can paste into this calculator is practically limited.
Is CRC32 the same thing as a hash like MD5 or SHA-256?
No — CRC32 is much faster but far weaker as a distinguishing check. It's designed to catch accidental corruption, not to be collision-resistant against deliberate tampering, which is what cryptographic hashes are built for.