CRC-32 Checksum Calculator
Compute the CRC-32 checksum of text or hex bytes, the ZIP and PNG standard.
What it does
CRC-32 is the workhorse checksum of file formats. ZIP archives, gzip streams, PNG chunks, and Ethernet frames all append one 32-bit value so readers can catch corruption with a glance at a lookup table.
The algorithm is a polynomial division done in binary. The data bytes stream through a register, and each bit shifts the polynomial in or out depending on the lowest bit, ending with a final inversion that gives the familiar eight hex digits.
The variant used here is the reflected one, polynomial 0xEDB88320, with initial value and final XOR both 0xFFFFFFFF. It has a famous property: the ASCII string 123456789, the standard test vector, hashes to CBF43926 in every conforming implementation from zlib to JavaScript.
Hex mode covers binary payloads. Paste bytes as 48 65 6C 6C 6F or with colons, dashes, or a 0x prefix, and the tool strips the separators before hashing. The result is the same value any packer or firmware tool would print.
One caveat matters more than the math: CRC-32 detects accidental errors, not deliberate ones. It is trivial to alter bytes and recompute a matching checksum, so never use it where a cryptographic hash or signature is the requirement.
How to use
- Choose text mode to hash a string as UTF-8.
- Choose hex mode to hash binary data.
- Type or paste the input.
- Read the checksum in hex, the format tools print.
- Compare against the value your archive tool reports.
- Check the byte count to confirm nothing was stripped.
Formula
- 0xEDB88320
- The reflected form of the standard CRC-32 polynomial 0x04C11DB7.
- 0xFFFFFFFF
- Initial register value and the value XORed back at the end.
- carry
- The lowest bit each step, which decides whether the polynomial is applied.
- byte count
- Data length in bytes; UTF-8 text can be longer than its character count.
The register starts all ones instead of zero, which catches leading zero bytes that would otherwise vanish from the arithmetic. Reflection means the least significant bit drives the loop, matching the way CRC-32 appears in ZIP, gzip, and PNG specifications. Because the polynomial is fixed and public, two different inputs can collide by design; that is a nuisance for deduplication but irrelevant for corruption detection.
Worked example
Example: the standard check value
Text mode with 123456789 (defaults).
- The nine digits become nine ASCII bytes.
- Each byte XORs into the running register and shifts eight times.
- The final inversion yields CBF43926 in hex.
- Decimal form: 3,421,780,262; bytes processed: 9.
- Hex mode mirror: 48656C6C6F spells Hello and hashes to F7D18982.
Reference table
| Input | CRC-32 |
|---|---|
| 123456789 | CBF43926 |
| Hello (hex 48656C6C6F) | F7D18982 |
| ABC | A3830348 |
| DE AD BE EF | 7C9CA35A |
| The quick brown fox jumps over the lazy dog | 414FA339 |
Limits
- 32-bit checksum only; CRC-16 and CRC-8 are different families.
- Not cryptographic: collisions are easy to construct on purpose.
- Text mode hashes UTF-8 bytes; an encoding mismatch changes the value.
- No file upload; large inputs should be pasted in chunks or hashed with a command line tool.
Common mistakes
- Using CRC-32 to verify integrity against tampering rather than accidents.
- Comparing a lowercase hex output against a lowercase-capable tool and assuming a mismatch.
- Odd digit counts in hex mode, which cannot form whole bytes.
- Hashing text on one system in UTF-8 and another in a legacy code page.
- Forgetting that the final XOR is part of the standard, not an optional tweak.
Try it yourself
Quick checks. Answers sit tucked under each question.
CRC-32 of ABC?
A3830348.
CRC-32 of hex bytes DEADBEEF?
7C9CA35A.
CRC-32 of Hello read as hex 48656C6C6F?
F7D18982.
Questions
Is CRC-32 encryption?
No. It is an error-detection checksum with no key. Anyone can compute it, and anyone can forge data with a matching value.
Why does ZIP use CRC-32?
It catches the transmission and storage errors that dominated magnetic media and networks, and it is fast enough to run over every byte without slowing unpacking.
Why is the output uppercase?
Convention from tooling like WinZip and PNG documentation. Case is cosmetic; the same digits mean the same value.
What is the check value?
Feeding the ASCII string 123456789 must produce CBF43926 in this parameter set. Every implementation that prints a different value uses a different polynomial, init, or reflection.
Can two different files share a checksum?
Yes, by the pigeonhole principle if nothing else: 32 bits cannot uniquely label every possible file. Accidental collisions are rare; deliberate ones take seconds.
Does the byte count matter?
It is your proof that nothing was trimmed in copy and paste. Whitespace is data in text mode, so a stray newline changes both the count and the checksum.
Sources
- W3C PNG specification appendix: CRC algorithm
- RFC 1952: GZIP file format specification (CRC-32 definition)