To generate a CRC32, run the input bytes through the CRC-32/ISO-HDLC algorithm with reflected polynomial 0xEDB88320, initial register 0xFFFFFFFF, reflected byte processing, and a final XOR of 0xFFFFFFFF, then format the resulting 32-bit register as eight lowercase hexadecimal digits. That formula is the one used by gzip, ZIP, PNG, Ethernet, and many other storage and transport formats, and it is the variant produced by the CRC32 Calculator. The 32-bit register is treated as an unsigned value, the result is padded on the left with zeros until it fills eight characters, and the standard reference check is that the nine ASCII bytes of "123456789" produce the eight-digit value cbf43926. If your target format lists any other polynomial, initial value, reflection setting, or final XOR, you are dealing with a different 32-bit CRC variant and a different tool.
CRC32 in general is a fast, table-driven checksum designed to catch accidental corruption of a byte sequence. It is not encryption, it is not a cryptographic hash, and it is not a signature. Knowing that distinction matters before you generate one: a CRC32 confirms that the bytes you fed in match the bytes the sender intended, but it does not prove who sent them. The rest of this article walks through which variant to pick, which input mode to use, and how to read and copy the eight-digit result without dropping a leading zero or comparing the wrong byte range.
Picking the right CRC-32 variant before you generate
The phrase "CRC32" in casual conversation almost always means CRC-32/ISO-HDLC, also called CRC-32/ISO 3309 or simply the gzip checksum. Several other 32-bit CRC formulas are in regular use and they are not interchangeable, which is the most common reason a generated value will not match an expected one. Picking the wrong variant is the first failure mode to rule out before suspecting any other mistake.
| Common 32-bit CRC variant | Where it appears | Same as CRC-32/ISO-HDLC? |
|---|---|---|
| CRC-32/ISO-HDLC (also called CRC-32) | gzip, ZIP, PNG, Ethernet, SSH, ITU-T V.42 | Yes — this is the one the calculator implements |
| CRC-32C (Castagnoli) | iSCSI, SCTP, ext4, BTRFS, FCoE | No — different polynomial |
| CRC-32/MPEG-2 | MPEG-2 transport streams, H.264 | No — same polynomial, no reflection, no final XOR |
| CRC-32/BZIP2 | bzip2 archive format | No — same polynomial, no reflection |
| CRC-32/JAMCRC | Build system hashes, some game files | No — same polynomial, no final XOR |
| CRC-32/Koopman | DVB, some telecom formats | No — different polynomial |
When the spec you are following names CRC-32 without a suffix, names it CRC-32/ISO-HDLC, or lists the gzip check value of cbf43926 for the nine ASCII bytes of "123456789", you are in the right place. When the spec names CRC-32C, Castagnoli, Koopman, MPEG-2, BZIP2, or JAMCRC, the result from this calculator will not match and you need a different tool. A second quick check is the format itself: if you are verifying a PNG file or a gzip member, you are asking for ISO-HDLC; if you are verifying an ext4 on-disk structure, you are asking for Castagnoli.
How to generate CRC32 from text or hex bytes
Open the CRC32 Calculator, choose the input mode that matches your payload, paste or type the bytes, calculate, and compare the full eight-digit result against your expected value. The interface is deliberately small so each step has a single decision. The procedure below covers the normal case; the following sections call out the edge cases that cause most mismatches.
- Identify the required CRC variant and the exact byte range to be covered. For ISO-HDLC the standard check value for the ASCII bytes of "123456789" is cbf43926; if your expected reference is anything else, you are not asking for the same variant and the result will not match.
- Choose between UTF-8 text mode and hexadecimal byte mode based on what the spec describes: text when the payload is genuinely a text string that will be encoded as UTF-8, hex when the spec names exact bytes or you have a raw byte sequence from a file or packet capture.
- Enter the payload exactly as it should be checksummed. In text mode, type the string with the exact characters and any line endings your target uses. In hex mode, paste pairs of hexadecimal digits with optional whitespace between them; the tool strips internal whitespace and treats each pair as one byte.
- Calculate. The browser builds a 256-entry lookup table from the reflected polynomial 0xEDB88320, initializes the register at 0xFFFFFFFF, processes each byte least-significant bit first, XORs the register with 0xFFFFFFFF at the end, and formats the unsigned 32-bit result as eight lowercase hex digits.
- Compare all eight digits with your expected value, including leading zeros. Use the copy control to copy exactly the displayed eight characters; the copy action does not add prefixes, separators, or surrounding whitespace.
- Decide whether the match is sufficient. A matching CRC32 is evidence that the bytes did not change accidentally; it is not a security proof. If hostile modification matters, use a cryptographic digest and an authenticated distribution channel instead.
Pick the right input mode: text versus hex
The two input modes look interchangeable but they almost never produce the same value for the same string. The reason is byte encoding. In text mode the calculator encodes your string as UTF-8 before feeding it to the CRC algorithm. ASCII characters contribute one byte each, while accented Latin letters, most CJK characters, and emoji contribute multiple bytes per visible character. The same logical string typed on a Windows machine with carriage-return-plus-linefeed endings, then pasted into a tool that normalizes to linefeed only, will produce a different CRC than the original.
| Question | UTF-8 text mode | Hexadecimal byte mode |
|---|---|---|
| What you type or paste | A readable string | Pairs of hex digits, with optional whitespace |
| Encoding applied to the input | UTF-8 (1 byte per ASCII char, more for accents and emoji) | None — the digits are interpreted as raw bytes |
| Best when | The target format describes the payload as text | The target format names the exact bytes or you have raw bytes |
| Most common mistake | Comparing across tools that disagree about newline endings | Including a 0x prefix, a stray separator, or an odd number of digits |
| Leading zero bytes | Cannot be expressed — they have no printable form | Must be entered as "00" pairs and will affect the result |
If a protocol, file format, or documentation gives you a literal byte sequence, paste it as hex instead of retyping it as visible text. Hex mode strips whitespace between byte pairs and otherwise requires an even number of hexadecimal digits; prefixes such as 0x, separators other than whitespace, comments, and an odd trailing nibble are rejected so the error is loud rather than silent. Confirm whether the byte range covered by the CRC includes any header, length field, delimiter, or stored checksum field, because adding or removing any of those changes the value.
Reading, comparing, and copying the eight-digit result
The output is always exactly eight lowercase hexadecimal digits, padded with leading zeros when the high bits are clear. That uniform width matters: a CRC of 0x0A1B2C3D is shown and copied as 0a1b2c3d, never as a1b2c3d or A1B2C3D, and the leading zero is preserved. When you compare against an expected value, look at all eight positions. A common failure mode is a tool that returns a decimal integer, an abbreviated hex string, or a 32-bit value with the bytes in reverse order; any of those will look wrong even when the underlying calculation is correct.
The copy action on the calculator copies only the eight displayed digits. It does not add a "0x" prefix, a colon, a space, a newline, or a trailing checksum field. If your downstream tool expects any of those, add them yourself after copying. The result is treated as unsigned throughout, so values above 0x7FFFFFFF are not sign-extended, and the value 00000000 is reserved for genuinely empty input; the interface asks for data so an accidental empty click does not look like a meaningful verification.
Limits, input size, and what the tool does not do
Input is limited to 5,000,000 bytes so that the table-driven processing remains responsive in the browser. For larger payloads, hash the file with a streaming tool first or split the input; the eight-digit output is exactly the same shape regardless of input length. The result is never silently truncated: if the calculation succeeds, you receive exactly eight hex digits, and if the input is rejected, the calculator reports the reason rather than producing a wrong-looking value.
Eight external check strings cover the empty input case, short messages, the common message-digest and alphabet suites, the standard numeric check for "123456789", and the quick-brown-fox sentence. A Python zlib cross-check is used for the multibyte UTF-8 boundary. These reference values prove that the declared variant and byte handling are correct rather than merely showing that an encoder agrees with its own decoder, which is the kind of self-consistency that catches no real bugs. If you want to understand the algorithm step by step rather than just receive the answer, the walkthrough in How to Calculate a CRC Checksum Step by Step shows the same reflected-polynomial method applied by hand to a short string.
When CRC32 is not enough for security
A matching CRC32 tells you that the bytes you have are the bytes that were checksummed, which is enough to catch accidental corruption on disk, on the wire, or in a partially downloaded file. It is not enough to catch hostile modification. CRC32 is linear and easy to manipulate: an attacker who wants a particular file to produce a chosen CRC32 can produce such a file without knowing the original. The same property means CRC32 cannot be used as a message authentication code, a digital signature, or proof that a download came from a trusted publisher.
Do not use CRC32 to verify untrusted software, to authorize commands, to protect credentials, or to establish that a file came from a trusted source. For those tasks use a cryptographic digest such as SHA-256 and confirm the digest through an authenticated channel. For authenticated integrity at the message level, use HMAC-SHA-256 or an equivalent authenticated encryption scheme. The CRC32 Calculator produces the right answer for accidental-error consistency; the broader security claim is up to you to make with a stronger primitive and a trustworthy comparison path.