CRC32 Generator — Free Online Tool

What is CRC32 Generator (IEEE 802.3 Checksum)?

CRC-32 is a 32-bit cyclic redundancy check that treats your data as the coefficients of a binary polynomial, divides it by a fixed generator polynomial, and keeps the remainder as a 32-bit fingerprint. This tool computes that remainder for any text using the IEEE 802.3 variant — the same one behind gzip, ZIP, PNG and Ethernet frame check sequences — and shows it in both hexadecimal and unsigned decimal.

• One well-defined variant: There are dozens of catalogued CRC-32 parameter sets and they produce different answers for the same input. This tool implements CRC-32/ISO-HDLC: reflected polynomial 0xEDB88320 (0x04C11DB7 in normal form), initial value 0xFFFFFFFF, reflected input and output, and a final XOR with 0xFFFFFFFF. Its check value for "123456789" is 0xCBF43926.
• Hex and decimal side by side: The hex field shows a 0x-prefixed, zero-padded eight-character value; the decimal field shows the same number as an unsigned 32-bit integer between 0 and 4,294,967,295. Both have their own Copy button, because tooling disagrees: PNG chunk dumps use hex, while zipinfo and many database columns use decimal.
• UTF-8 bytes, not characters: The text you type is encoded as UTF-8 before the checksum runs, so non-ASCII characters contribute two to four bytes each. The pure function underneath also accepts raw bytes, which is how the Checksum Calculator applies the identical algorithm to uploaded files.
• Error detection, not security: CRC-32 was designed to catch accidental corruption — noise on a wire, a flipped bit in storage, a truncated transfer — and it is excellent at that. It is linear and unkeyed, so anyone can compute bytes that force a chosen checksum. It is a checksum, not a cryptographic hash, and it must never be used to prove that data was not tampered with.
• Instant and local: A 256-entry lookup table is built once and reused, so results refresh as you type. Nothing is uploaded; the whole computation happens in the page.

Why use the CRC32 Generator?

CRC-32 is the checksum that formats and protocols actually use, so being able to compute it by hand is what lets you read a file header, validate a frame, or reproduce a value some other tool reported.

• Read and repair archive and image metadata: ZIP local file headers, gzip trailers and every PNG chunk carry a CRC-32. When an archive reports a checksum error or a PNG viewer rejects a chunk, computing the value yourself tells you whether the stored checksum or the stored data is the thing that is wrong.
• Cheap deduplication and change detection: For trusted data, a 32-bit checksum is a fast way to notice that something changed — cache invalidation, rsync-style block comparison, or spotting an unmodified config file — without storing or transferring the content itself.
• Compact keys and short identifiers: Eight hex characters fit in a filename, a log line, a build tag or a fixed-width column where a 64-character SHA-256 digest will not. Many build systems and CDN cache-busters use exactly this for that reason.
• Embedded and protocol work: Serial links, CAN, firmware images, bootloader headers and industrial protocols all specify a CRC field. Reproducing the expected value on a desktop is the fastest way to confirm a device is using the parameter set the datasheet claims.
• Reconcile mismatched tools: Two utilities reporting different "CRC32" values for the same file usually differ in variant — CRC-32C uses the Castagnoli polynomial, BZIP2 uses non-reflected parameters. Comparing against the known IEEE check value here identifies which one you are looking at.

When to use the CRC32 Generator

Use it whenever a 32-bit checksum field needs to be produced, verified or explained — and never as a substitute for a cryptographic digest.

• Debugging a ZIP, gzip or PNG file whose stored CRC does not match its payload, to determine which side is corrupt.
• Filling in a checksum field in a firmware image, bootloader header or serial protocol frame during embedded development.
• Verifying that a file transfer, serial dump or database export arrived intact when both ends are trusted and speed matters more than tamper resistance.
• Generating short, stable identifiers for cache keys, sharding, filenames or log correlation where eight hex characters is the budget.
• Reproducing the CRC value that another tool printed — unzip -v, gzip -l, cksum, zlib.crc32, PHP's crc32() — to confirm you are using the same variant.
• Converting between the hex and unsigned-decimal forms of a checksum, which is the difference between 0x0d4a1185 and 222957957.
• Teaching or reviewing why a linear checksum cannot detect deliberate modification, using a concrete pair of values.

How to use the CRC32 Generator

One input, two output formats, recalculated automatically as you type.

1. Paste the text: Put the exact content in the Input box. Watch for a trailing newline: shell tools like echo add one, and it changes the checksum completely.
2. Read the hex value: The CRC-32 (hex) field shows the result as 0x followed by eight lowercase hex digits, zero-padded. This is the form that appears in file-format dumps and hex editors.
3. Read the decimal value: The CRC-32 (decimal) field shows the same 32-bit number unsigned. Use it when comparing against zlib.crc32 in Python, PHP's crc32(), or a numeric database column.
4. Copy the form you need: Each field has its own Copy button and the status line confirms the copy. Strip the 0x prefix yourself if the destination expects bare hex digits.
5. Verify your parameter set: Type 123456789 — if you get 0xcbf43926 you are looking at the standard IEEE 802.3 CRC-32, which is the variant zlib, gzip, ZIP and PNG all use. Any other value means a different polynomial or reflection setting.
6. Switch tools for files or security: For a file rather than typed text, use the Checksum Calculator, which runs the same CRC-32 over raw bytes alongside SHA digests. For anything that must resist tampering, use SHA-256 instead.

Key features

• Standard IEEE 802.3 parameters: Reflected polynomial 0xEDB88320, init 0xFFFFFFFF, reflected in and out, final XOR 0xFFFFFFFF — byte-identical to zlib, gzip, ZIP and PNG.
• Dual output format: 0x-prefixed eight-digit hex and unsigned 32-bit decimal, each with its own Copy button, so you can match whatever a header dump or library reports.
• Table-driven implementation: The 256-entry lookup table is generated once and cached, so long inputs stay instant and results update as you type.
• Shared with the file tools: The same pure function backs the Checksum Calculator and the Hash Verification tool, so a text CRC and a file CRC of identical bytes always agree.
• Byte-accurate UTF-8 encoding: Input is encoded exactly as TextEncoder does it, so multi-byte characters are checksummed as the bytes a file would actually contain.
• Runs offline: No network request, no upload, no server-side computation — the checksum is produced in your browser tab.

Common use cases

• Archive and image forensics: Check a PNG chunk CRC or a ZIP entry checksum by hand to decide whether a file is genuinely corrupt or merely mis-parsed.
• Embedded firmware: Produce the CRC-32 a bootloader expects in an image header, or verify a value a device reported over a serial console.
• Build and cache fingerprints: Generate short stable identifiers for asset filenames, cache keys and CDN busting where a full hash is overkill.
• Data pipeline sanity checks: Compare CRCs of a record batch before and after transfer between trusted systems to catch truncation and encoding damage early.
• Cross-language verification: Confirm that Python's zlib.crc32, Java's java.util.zip.CRC32, Go's hash/crc32 IEEE table and PHP's crc32() all agree with the value here.
• Teaching integrity concepts: Demonstrate the gap between error detection and tamper resistance using a checksum whose collisions are easy to reason about.

Examples

Both output formats are shown for each input, computed from the exact bytes with no trailing newline.

123456789

hex: 0xcbf43926
decimal: 3421780262

hello world

hex: 0x0d4a1185
decimal: 222957957

hello worlds

hex: 0x86d1f2b5
decimal: 2261906101

hex: 0x00000000
decimal: 0

The quick brown fox jumps over the lazy dog

hex: 0x414fa339
decimal: 1095738169

Technical reference

The exact parameter set and the numbers that follow from it:

Algorithm name

CRC-32/ISO-HDLC, also catalogued as CRC-32/ADCCP, PKZIP and "CRC-32" without qualification

Polynomial

0x04C11DB7 in normal form, 0xEDB88320 reflected — the same generator used by IEEE 802.3 Ethernet

Width and range

32 bits — 8 hex characters, unsigned decimal 0 to 4,294,967,295

Initial value

0xFFFFFFFF

Reflection

Input reflected, output reflected (bit order reversed within each byte)

Final XOR

0xFFFFFFFF

Check value

CRC-32("123456789") = 0xCBF43926 — the standard catalogue value for this parameter set

Used by

gzip (RFC 1952), ZIP, PNG chunk CRCs, Ethernet frame check sequence, zlib's crc32()

Collision expectation

Roughly 77,000 random inputs give a 50% chance of a collision by the birthday bound — fine for noise detection, useless against an adversary

Common mistakes to avoid

Using CRC-32 to verify that a file has not been tampered with

Why it happens: CRC-32 is linear over GF(2), which means the checksum of a modification is related to the modification itself in a way an attacker can solve. Given any target value, you can compute four bytes to append — or bits to flip in a region you control — that force the CRC to whatever you want, in microseconds and with no brute force. Add the tiny 32-bit output space, where a random collision appears after about 77,000 inputs, and a matching CRC provides no evidence at all that a file is the one you intended to receive.

How to avoid it: Use CRC-32 only for accidental-corruption detection over data you already trust. When the data crosses a trust boundary, use SHA-256 and obtain the expected digest through an independent, authenticated channel — a signed release manifest, HTTPS from the vendor, a package signature. When you need to prove origin as well as integrity, use HMAC-SHA-256 or a digital signature so the value cannot be recomputed without a secret.

Assuming every "CRC32" means the same algorithm

Why it happens: The name is badly overloaded. CRC-32/ISO-HDLC (this tool, zlib, gzip, ZIP, PNG) reflects input and output and XORs the result. CRC-32/BZIP2 uses the same polynomial with no reflection. CRC-32C uses the entirely different Castagnoli polynomial 0x1EDC6F41 and is what SCTP, iSCSI, Btrfs and ext4 use, with hardware support in the SSE4.2 CRC32 instruction. CRC-32/MPEG-2, POSIX cksum and JAMCRC differ again. All are eight hex characters, so a mismatch looks like corruption rather than a configuration difference.

How to avoid it: Identify the variant before comparing values. Feed "123456789" through both tools: 0xCBF43926 is ISO-HDLC, 0xFC891918 is BZIP2, 0xE3069283 is CRC-32C. Then read the specification of whatever format you are working with, since it will name the parameter set. Note also that POSIX cksum includes the file length in its calculation, which is why its output never matches a plain CRC-32 of the same bytes.

Comparing a signed and an unsigned decimal CRC

Why it happens: A CRC-32 is an unsigned 32-bit value, but several languages return it in a signed 32-bit integer. Java's CRC32.getValue() returns a long and is fine, but a value that has passed through an int, or PHP's crc32() on a 32-bit build, can come back negative: 2261906101 becomes -2033061195, the same bit pattern read as two's complement. Comparing that against an unsigned value fails, and storing it in a signed database column silently mangles half of all possible checksums.

How to avoid it: Normalise to unsigned before comparing or storing. In JavaScript apply >>> 0, in Python use zlib.crc32(data) & 0xFFFFFFFF, in PHP use sprintf('%u', crc32($s)). Better still, store and compare the eight-character hex form, which has no sign ambiguity and no platform-dependent integer width. If you inherit a negative value, add 4294967296 to recover the unsigned equivalent.

Forgetting the trailing newline that a shell added

Why it happens: CRC-32 is byte-exact, and command-line pipelines routinely add bytes you did not type. echo appends a newline unless you pass -n, text editors add a final newline by convention, and a Windows checkout turns each LF into CRLF. CRC-32 of "hello world" is 0x0d4a1185, while the same text with one trailing newline is 0xaf083b2d — nothing in either value hints that a single invisible byte is the difference.

How to avoid it: Use printf '%s' instead of echo, or echo -n, when checksumming a literal string on the command line. Compare byte counts before you compare checksums; the status line here reports the character count of your input. For files, check the last byte with a hex viewer, and set .gitattributes or your editor to keep line endings consistent across platforms so the same file does not checksum differently on two machines.

Using CRC-32 as a hash table or database key at scale

Why it happens: Thirty-two bits sounds like a lot until the birthday bound is applied: at roughly 77,000 distinct values you have a 50% chance of a collision, and at a few hundred thousand rows collisions become routine. If your code treats the CRC as a unique key, that surfaces as records overwriting each other, cache entries returning the wrong content, or a unique-constraint violation that looks impossible. CRC-32 also has poor avalanche behaviour compared with a real hash, so structured inputs cluster more than random ones.

How to avoid it: Treat a CRC as a fast pre-filter, never as an identity. Use it to find candidate matches, then confirm with a full comparison of the underlying data. If you need a compact unique key, use a wider hash — the first 16 bytes of SHA-256 gives 128 bits — or a purpose-built identifier such as a UUIDv7, ULID or Snowflake ID, all of which are generated by other tools here.

Frequently asked questions

Is CRC32 a hash function or a checksum?

It is a checksum. Both map data to a fixed-length value, but a cryptographic hash additionally makes it infeasible to find collisions or to engineer a specific output, and CRC-32 makes no such guarantee. Because CRC arithmetic is linear, you can compute exactly which bytes to add or flip to force any checksum you choose, and the 32-bit space is small enough that accidental collisions appear after tens of thousands of inputs. CRC-32 is superb at detecting the burst errors it was designed for and worthless against an adversary — use SHA-256 whenever the data comes from somewhere you do not control.

Why do two programs give different CRC32 values for the same data?

Almost always a different variant or different bytes. CRC-32 has many parameter sets: ISO-HDLC (zlib, gzip, ZIP, PNG, and this tool), BZIP2, CRC-32C/Castagnoli, MPEG-2, JAMCRC and POSIX cksum, which also folds in the file length. Run "123456789" through both tools — 0xCBF43926 identifies ISO-HDLC. If the variants match, the inputs differ: check for a trailing newline, CRLF line endings, a byte-order mark, or a text-mode transfer that rewrote line breaks. Comparing byte counts first usually finds it faster than comparing checksums.

How do I convert a CRC32 between hex and decimal?

They are two renderings of the same 32-bit number, and this tool shows both at once so no conversion is needed. Manually, 0x0d4a1185 is 222957957 and the reverse is parseInt('0d4a1185', 16) in JavaScript or int('0d4a1185', 16) in Python. Two details matter: keep the eight-digit zero padding, because 0x0d4a1185 written as 0xd4a1185 will be misread by fixed-width parsers, and make sure the decimal is unsigned — languages that return a signed 32-bit integer report 0x86d1f2b5 as -2033061195 rather than 2261906101.

Can two different files have the same CRC32?

Yes, and it is not rare. There are only 2^32 possible checksums, so by the birthday bound about 77,000 random inputs give a 50% chance that two share a value, and any collection of a few hundred thousand items will contain collisions. Deliberate collisions are trivial: the algorithm's linearity lets anyone construct a file with a chosen CRC in microseconds. This is why archive formats use CRC-32 to detect a corrupted extraction, not to authenticate content, and why a matching CRC should never be treated as proof that two files are identical.

Which CRC32 does gzip, ZIP and PNG use?

All three use the variant this tool implements: polynomial 0x04C11DB7 (0xEDB88320 reflected), initial value 0xFFFFFFFF, reflected input and output, final XOR 0xFFFFFFFF — the same generator as the Ethernet frame check sequence. gzip stores it in the four-byte trailer alongside the uncompressed size, as specified in RFC 1952. ZIP stores it in each local file header and central directory entry. PNG appends a CRC to every chunk, covering the chunk type and data but not the length field. zlib's crc32() and Python's zlib.crc32 produce the same values.

Should I use CRC32 or SHA-256 for file integrity?

It depends who you are defending against. If the risk is accidental damage — a flaky USB cable, a truncated download from a source you trust, bit rot on disk — CRC-32 is fast, compact and entirely adequate, which is why storage and network hardware use it. If the file crosses a trust boundary, or the expected value could have been altered by whoever altered the file, use SHA-256 and get the reference digest from an independent authenticated source. Where you also need to prove who produced the file, move up to HMAC-SHA-256 or a digital signature.

Does CRC32 work on binary files, not just text?

Yes. CRC-32 operates on bytes and has no notion of text or encoding, so any byte sequence works. This particular page takes typed text and encodes it as UTF-8 first, which is the right behaviour for a text box. For actual files, use the Checksum Calculator, which reads the file as an ArrayBuffer and runs the same CRC-32 function over the raw bytes alongside SHA-1, SHA-256, SHA-384 and SHA-512. That distinction matters for binaries, where any text transformation — line-ending conversion in particular — would change the result.

References

• RFC 1952 — GZIP file format specification version 4.3
• PNG Specification (Third Edition) — Cyclic Redundancy Code algorithm
• Catalogue of parametrised CRC algorithms — CRC-32 variants
• zlib Manual — crc32()
• IEEE 802.3 Ethernet Standard