CRC32 is a 32-bit cyclic redundancy check value computed from a sequence of bytes using a fixed polynomial and a small set of bookkeeping rules, and "finding" a CRC32 in practice means producing the same eight-digit lowercase hexadecimal that the format or protocol expects. The standard CRC-32/ISO-HDLC variant, used by gzip, ZIP, PNG and many other consumer formats, returns cbf43926 for the ASCII bytes of "123456789"; if your result does not match that test value, you are not looking at the same variant at all. Because the algorithm is defined at the byte level, the result also depends on the exact byte sequence you feed in: the encoding of text, the line-ending convention, and whether any header, length field, or stored checksum is included in the covered range all change the output. The CRC32 Calculator on this site implements CRC-32/ISO-HDLC with reflected polynomial 0xEDB88320, init and final XOR 0xFFFFFFFF, and the standard check value cbf43926, which is the variant you want for almost every common consumer format you will encounter.
Why "CRC32" Is Not a Single Formula
CRC32 names a 32-bit checksum produced by a deterministic algorithm that walks every byte of a message, mixes each byte into a fixed-width register using a polynomial, and finally XORs the register with a constant. The result is eight hexadecimal digits. It is fast, lightweight, and excellent at catching accidental corruption from noisy channels, partial downloads, or bad disk blocks, which is why file formats such as ZIP, PNG, gzip, and many others include a CRC32 field.
The trouble is that "CRC32" is not a single formula. The same name covers dozens of variants with different polynomials, initial register values, reflection flags, and final XOR values. The variant used by gzip, ZIP, and PNG is CRC-32/ISO-HDLC: width 32, reflected polynomial 0xEDB88320, init 0xFFFFFFFF, reflected input, final XOR 0xFFFFFFFF. The variant used by iSCSI, SCTP, and modern CPUs that implement CRC32C instructions is Castagnoli, with a different polynomial and a different check value. Some systems use MPEG-2 or BZIP2 variants, which differ in either the reflection or the final XOR. If you try to find a CRC32 with the wrong variant, the calculator is correct, but the answer is wrong for the file you intended to check.
This is why the first job is not to compute but to identify which variant the spec, format, or program expects, and then to make sure the byte sequence you feed in matches the byte sequence the spec covers.
Identify the Exact Variant and Byte Range Before You Compute
Two things must match before you can find a CRC32 that lines up with a reference: the variant and the covered byte range.
For the variant, check the documentation of the format that publishes the expected value. PNG, gzip, and ZIP produce CRC-32/ISO-HDLC values with reflected polynomial 0xEDB88320 and the standard check value cbf43926 for the ASCII bytes of "123456789". Btrfs, iSCSI, and SCTP use CRC-32C (Castagnoli). The CRC32 Calculator on this site only implements CRC-32/ISO-HDLC; if the expected check for "123456789" is not cbf43926, you need a different tool.
For the byte range, identify exactly which bytes the checksum is computed over. Some formats cover the raw payload only. Others include a header, a length field, delimiters, or a stored checksum field. Covering extra bytes or skipping required bytes will silently produce a value that does not match the spec, even with the right variant.
The table below lists a few widely deployed CRC-32 variants and the parameters that distinguish them. Use it to confirm the variant your spec requires before you compute.
| Variant | Polynomial | Init | XOR out | Check value for "123456789" |
|---|---|---|---|---|
| CRC-32/ISO-HDLC (gzip, ZIP, PNG) | 0xEDB88320 | 0xFFFFFFFF | 0xFFFFFFFF | 0xCBF43926 |
| CRC-32C (Castagnoli, iSCSI, SCTP) | 0x82F63B78 | 0xFFFFFFFF | 0xFFFFFFFF | 0xE3069283 |
| CRC-32/MPEG-2 | 0x04C11DB7 | 0xFFFFFFFF | 0x00000000 | 0x0376E6E7 |
| CRC-32/BZIP2 | 0x04C11DB7 | 0xFFFFFFFF | 0xFFFFFFFF | 0x0FC89198 |
| CRC-32/JAMCRC | 0x04C11DB7 | 0xFFFFFFFF | 0x00000000 | 0x340BC6D9 |
The CRC32 Calculator implements only the first row. If your spec names a different variant, you need a different implementation; the algorithm, the table, and the final XOR all change, so a single calculator cannot serve every variant.
Enter Your Data and Get the Eight-Digit Result
Once you have confirmed the variant and byte range, the calculator does the rest. The following steps produce a CRC32 that matches the spec.
- Open the CRC32 Calculator in your browser. The page is fully client-side, so the input never leaves your machine.
- Decide whether your payload is text or raw bytes. Use text mode only when the spec names the input as a UTF-8 string. Use hex mode whenever a protocol gives you an exact byte sequence, when the original bytes came from a file, or when the encoding might be ambiguous.
- Paste the payload into the input field. In hex mode, paste pairs of digits; whitespace between pairs is allowed and is stripped automatically. Prefixes such as 0x, separators other than whitespace, comments, and odd trailing nibbles are rejected so the parser never has to guess.
- Click calculate. The tool encodes the text as UTF-8 in text mode, treats the hex string as raw bytes in hex mode, and walks the bytes through a 256-entry table built from the reflected polynomial 0xEDB88320 with init 0xFFFFFFFF and final XOR 0xFFFFFFFF. The implementation follows the practical sample method described in RFC 1952 rather than relying on browser-specific number formatting.
- Read the eight-digit lowercase hexadecimal result. The page always shows all eight digits, with leading zeros preserved, and treats the value as unsigned regardless of how the browser would format a 32-bit signed number.
- Copy the result with the copy button. Only the exact 32-bit value is copied, with no surrounding text or formatting.
The result is computed entirely in the browser using the table-driven method, and a Python zlib cross-check is used for the multibyte UTF-8 boundary. The input limit is 5,000,000 bytes so table lookup remains responsive on typical hardware.
Read the Output and Compare It Correctly
A correct CRC32 result is always exactly eight lowercase hexadecimal digits. Leading zeros are part of the result, not padding to be stripped. The value 00000000 is a meaningful checksum for an empty payload, although the interface asks for data so accidental empty clicks do not look like a meaningful verification.
When comparing two CRC32 values, character-by-character match is the only test. Different casing, missing leading zeros, or extra formatting does not help: "CBF43926", "cbf43926", and "0cbf43926" represent different strings but the same numeric value, and the calculator only emits eight lowercase digits. Compare them as text, or convert each to an integer and compare integers.
If you are cross-checking against a published check value, the standard test for CRC-32/ISO-HDLC is the ASCII bytes of "123456789". The expected value is cbf43926. If your tool produces a different value, one of three things is true: you are using a different variant, the bytes you fed in are not the ASCII bytes of "123456789", or the byte range covered is different from the spec. Re-confirm the variant and the byte range before treating the mismatch as a real software bug.
Empty input is a quick sanity check. The standard CRC-32/ISO-HDLC value for an empty byte sequence is 00000000, which follows directly from init and final XOR both being 0xFFFFFFFF. Cross-check against a known reference such as Python's zlib.crc32(b"") to confirm the variant and the byte handling. You can also confirm multibyte handling with a UTF-8 boundary string such as "é" or a CJK character, which encodes to multiple bytes and must be passed as UTF-8 to produce a stable result.
When CRC32 Is Not Enough and You Need Authentication
A matching CRC32 is evidence that two byte sequences are probably the same modulo accidental corruption. It is not evidence that the data is authentic, that it came from a trusted publisher, or that it has not been replaced by an attacker. The CRC32 algorithm is linear in its inputs and short of the inputs, which makes it cheap to construct a payload that produces a chosen CRC32. The zlib manual explicitly distinguishes the CRC32 checksum from cryptographic authentication and recommends cryptographic digests where authenticity matters.
For adversarial integrity, use a cryptographic digest such as SHA-256 over the same byte sequence, published by a publisher you trust through a channel you can verify, and verify the digest against both the file and the expected value. CRC32 is the right tool for catching noisy-channel corruption in non-adversarial settings: verifying that a downloaded file is not truncated, that a transferred block is not damaged, that a stored chunk matches what was written, or that a custom format's integrity field is correct. It is the wrong tool for authorizing commands, protecting credentials, verifying untrusted software, or establishing the origin of a file.
What Causes CRC32 Mismatches
Most failed CRC32 lookups come from a small number of recurring mistakes. Avoiding them is usually faster than debugging the algorithm.
The most common mistake is feeding in the wrong encoding. In text mode the calculator encodes the input as UTF-8. ASCII characters contribute one byte, while accented letters, CJK characters, and emoji contribute multiple bytes. A result computed over UTF-16 code units, a legacy character set, or normalized text will differ. If your spec hands you exact bytes, use hex mode instead of retyping them as visible text.
The second is the newline convention. LF and CRLF produce different bytes, so the same logical line produces a different CRC32 on Unix and Windows. If the spec does not specify, normalize the input and document which convention you used.
The third is hidden header or framing bytes. ZIP local file headers, gzip member headers, and PNG chunk headers are not always included in the covered range. If you compute CRC32 over the raw payload but the spec expects it over the header plus payload, the values will not match. Always confirm whether the target specification includes headers, length fields, delimiters, or a stored checksum field in the covered range.
The fourth is leading zeros. In hex mode, every two digits become one byte, and leading 00 bytes are preserved. Dropping a leading 00 byte shortens the input by one byte and changes the CRC32. If the hex entry rejects odd-length input, that is the parser refusing to guess which side a stray nibble belongs to.
The fifth is confusing CRC32 with a cryptographic hash. CRC32 is shorter, faster, linear, and unauthenticated. If you need forgery resistance, use SHA-256 or HMAC-SHA-256 and a trusted channel, and never rely on a CRC32 match to verify downloadable software.