CRC-32/ISO-HDLC is the specific 32-bit cyclic redundancy check used by gzip, ZIP, PNG, Ethernet, and many archival formats, defined by a width of 32, reflected polynomial 0xEDB88320, initial register 0xFFFFFFFF, reflected byte processing, and a final XOR of 0xFFFFFFFF. This CRC32 Calculator cheat sheet pins down every fixed parameter, byte-handling rule, and reference check value so you can compute the same eight-digit hexadecimal result as any conformant implementation. The standard sanity check for the ASCII bytes of 123456789 is cbf43926 — if a tool produces a different eight-digit value for that string, you are looking at a different CRC-32 formula such as CRC-32C, MPEG-2, BZIP2, or JAMCRC. Calculation runs locally in the browser, no input is uploaded, and the copy button returns the exact 32-bit value formatted as eight lowercase hexadecimal digits with leading zeros preserved.
CRC-32/ISO-HDLC Parameters at a Glance
The calculator locks a single variant — CRC-32/ISO-HDLC — and does not switch formulas based on guesswork. Every implementation detail is fixed so the eight-digit output is reproducible across browsers, operating systems, and programming languages. The parameter table below is the contract the calculator honors on every run, regardless of which mode you choose or which characters you paste.
| Parameter | Value |
|---|---|
| Width | 32 bits |
| Polynomial (reflected) | 0xEDB88320 |
| Initial register | 0xFFFFFFFF |
| RefIn (input bytes) | true (LSB-first) |
| RefOut (output register) | true |
| XorOut (final XOR) | 0xFFFFFFFF |
| Check value for ASCII 123456789 | 0xCBF43926 |
These values mirror the RFC 1952 sample method for gzip and the same polynomial that powers ZIP local-header CRCs and PNG chunk CRCs. Because the table-driven implementation processes every byte least-significant-bit first and complements the register at the end, leading-zero results such as 000000d4 still appear with their zeros intact rather than collapsing to a shorter string.
How to Get Your CRC32 in Three Steps
The full workflow fits three concrete moves once you know which variant your target format expects. Open the CRC32 Calculator and follow the steps below.
- Identify the required CRC variant and the exact byte range the target specification covers. This page implements CRC-32/ISO-HDLC with check value cbf43926 for 123456789, so any spec that cites a different check value or a name such as Castagnoli, MPEG-2, BZIP2, or JAMCRC will not match.
- Choose UTF-8 text or hexadecimal bytes, enter the exact payload, and calculate. In text mode, paste the visible characters and the calculator encodes the bytes for you. In hex mode, paste an even number of hex digits and the calculator strips whitespace and treats every pair as one byte.
- Compare all eight digits with the expected value and copy the result. Use a cryptographic authentication mechanism when hostile modification matters; a matching CRC is evidence of accidental-error consistency only.
For a deeper walkthrough on identifying the variant before you calculate, the matching guide on picking the right CRC32 variant and byte range pairs naturally with this cheat sheet.
The Standard Check Value: cbf43926 for 123456789
The single most useful sanity check for any CRC-32/ISO-HDLC tool is the nine ASCII bytes of the string 123456789. Every conformant implementation, from zlib's crc32 to PNG chunk validators, produces 0xCBF43926 for that input. If the calculator you are testing gives anything else, the tool is using a different polynomial, a different initial value, or processing the bytes in a different order.
| Reference input | Expected 32-bit CRC | Notes |
|---|---|---|
| Empty input | 0x00000000 | Programmatic placeholder; the interface asks for data so accidental empty clicks do not look like a meaningful verification. |
| ASCII 123456789 | 0xCBF43926 | Standard numeric check used to distinguish ISO-HDLC from other 32-bit formulas. |
| Mismatched variant | anything else | A different eight-digit value indicates CRC-32C, MPEG-2, BZIP2, JAMCRC, or a non-conformant implementation. |
Keep this row handy whenever you switch between tools, languages, or hardware blocks. A Python zlib cross-check is the fastest way to confirm that a browser-based result agrees with a battle-tested reference implementation.
Text Mode vs Hex Mode: Byte Handling Rules
Text mode and hex mode look similar but enforce different byte contracts, and confusing them is the single most common reason a "correct" result looks wrong.
Text mode is the right pick only when UTF-8 is explicitly the byte encoding the target format expects. The calculator encodes the string as UTF-8 before processing it, so ASCII characters contribute one byte, while many accented letters contribute two bytes, CJK characters contribute three bytes, and emoji or characters outside the Basic Multilingual Plane contribute four bytes. A result calculated over UTF-16 code units, a legacy character set, normalized text, or a different newline convention will differ even when the visible string looks identical to a casual reader.
Hex mode is the right pick when a protocol, file format, or wire format gives you exact bytes. The calculator removes any whitespace between byte pairs but otherwise requires an even number of hexadecimal digits, rejects prefixes such as 0x, separators other than whitespace, comments, and odd trailing nibbles. Each pair becomes one byte, leading 00 bytes are preserved and affect the result, and the eight-digit output treats the value as unsigned so leading zeros always appear in the display.
The rule of thumb is simple: when a specification gives you exact bytes, paste them as hex instead of retyping them as visible text. The relationship between the two modes is best verified by running the same payload in both modes and comparing the eight-digit results against a trusted reference such as Python's zlib.crc32.
Common Pitfalls That Break the Match
Even when the variant is correct and the tool is conformant, small input choices can shift the output to a completely different eight-digit value.
- Including or excluding headers, length fields, delimiters, or a stored checksum field changes the covered byte range and therefore the result. Confirm with the governing format whether those bytes sit inside or outside the CRC.
- Re-typing binary data as visible text instead of pasting the bytes as hex silently swaps bytes such as 0x0A for the literal characters backslash-n when the source was an escape sequence.
- Normalizing line endings, converting tabs to spaces, or stripping trailing whitespace produces different byte counts and therefore a different CRC.
- Treating leading 00 bytes as ignorable drops them from the calculation; the calculator preserves them on purpose so the eight-digit output matches a hex dump byte-for-byte.
- Reading a CRC value back as a signed 32-bit integer produces a negative number for any result with the high bit set, which then fails an unsigned string match. Always compare the eight hexadecimal digits as characters.
If the calculator and your reference disagree on a payload you trust, walk back through these pitfalls before suspecting the tool or the polynomial.
What CRC32 Does Not Do: Security Boundaries
CRC32 is an integrity checksum designed to detect common accidental changes in data, not an adversarial control. It is linear, easy to manipulate intentionally, and collisions can be constructed without knowing the original payload. Treat a matching CRC32 as evidence that a transfer, copy, or decompression step did not flip a few bits at random, and nothing more.
CRC-32 is not encryption, not a cryptographic hash, not a message authentication code, not a digital signature, and not proof of origin. Do not use it to verify untrusted software, authorize commands, protect credentials, or establish that a file came from a trusted publisher. For those jobs use a cryptographic digest such as SHA-256 and an authenticated distribution channel — for example, an out-of-band signature from the publisher alongside HTTPS — and treat the CRC32 inside ZIP, PNG, or gzip frames as a secondary sanity check rather than a security control.
Different systems use names such as CRC32, CRC-32C, Castagnoli, Koopman, MPEG-2, BZIP2, and JAMCRC for formulas with different polynomials or initial and final transformations. Because the calculator implements only CRC-32/ISO-HDLC, the eight-digit output is meaningful only against specs that share the same reflected polynomial 0xEDB88320 and the same 0xFFFFFFFF initial and final XOR. When the expected check for 123456789 is not cbf43926, the other system almost certainly uses a different variant or a different byte range, and a different tool is the right starting point.