Hex CRC Calculator
Compute a CRC checksum from hex byte input, using the CRC-32/ISO-HDLC variant — the same algorithm ZIP, PNG, and gzip use for error detection.
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 CRC Error Detection Works
CRC treats the input bytes as one large binary number and divides it by a fixed "generator" polynomial, keeping the remainder as the check value. Because polynomial division is sensitive to almost any bit change in the input, a corrupted byte almost always produces a different CRC — which is what makes it useful for catching transmission or storage errors.
Common CRC Variants
"CRC" by itself doesn't specify which variant — here's where the most common ones are actually used.
| Variant | Width | Where it's used |
|---|---|---|
| CRC-32/ISO-HDLC | 32-bit | ZIP, PNG, gzip, Ethernet (what this calculator computes) |
| CRC-16/MODBUS | 16-bit | Modbus industrial protocol |
| CRC-8 | 8-bit | Small embedded protocols, SMBus |
| CRC-32C (Castagnoli) | 32-bit | iSCSI, ext4, Btrfs — a different polynomial than ISO-HDLC |
Where Hex CRC Actually Comes Up
Verifying a File Wasn't Corrupted
Comparing a freshly computed CRC against a published or previously stored value quickly confirms whether file contents changed, without needing to compare the entire file byte by byte.
computed CRC == expected CRC
Checking a Protocol Frame
Many binary protocols append a CRC to each frame or packet — computing the CRC over the received bytes and comparing it to the trailing value is how the receiver detects transmission errors.
frame bytes + CRC trailer
Debugging a Custom CRC Implementation
When writing CRC code from scratch (in an embedded project, for instance), checking your implementation against a known test vector like the standard "123456789" check value catches bugs before they reach production.
CRC32("123456789") == 0xCBF43926
Why Use This Calculator Instead of Doing It by Hand
- Verified against the official CRC-32/ISO-HDLC check value (0xCBF43926 for "123456789")
- Table-driven implementation, so even long byte sequences compute instantly
- Runs entirely in your browser — nothing you type gets sent anywhere
- Accepts hex byte input directly, no need to convert from ASCII first
Limitations
- Computes only the CRC-32/ISO-HDLC variant — CRC-16, CRC-8, and CRC-32C (Castagnoli) use different polynomials and will not match this output.
- 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
Which CRC algorithm does this calculator use?
CRC-32/ISO-HDLC (often just called "CRC32") — the same variant used by ZIP, PNG, and gzip. "CRC" alone is ambiguous since dozens of CRC variants exist (CRC-8, CRC-16, different CRC-32 polynomials), so this calculator standardizes on the one you'll encounter most often.
Why are there so many different CRC variants?
Each variant picks a different generator polynomial, initial value, and output handling — tuned for different bit widths and error patterns. They all work on the same underlying principle (polynomial division), but produce different check values for the same input.
How is CRC different from a simple additive checksum?
A plain checksum just adds up byte values, which misses many corruption patterns (like two bytes swapping). CRC uses polynomial division instead, which catches a much wider range of accidental bit errors — that's why it's the standard for file formats and network protocols.
Can I verify this calculator's CRC32 output against a known value?
Yes — the standard CRC-32/ISO-HDLC check value for the ASCII bytes "123456789" is 0xCBF43926. Enter 313233343536373839 (the hex bytes for that ASCII string) to see this calculator produce the same result.
Is CRC a cryptographic hash?
No — CRC is designed to catch accidental corruption, not resist intentional tampering. It's fast and effective for detecting a flipped bit or dropped byte, but someone deliberately altering data can trivially produce a matching CRC. Use a cryptographic hash (like SHA-256) for security-relevant integrity checks.