This tool computes the CRC-32 checksum of any text and shows it in both hexadecimal and unsigned decimal, updating live as you type. CRC-32 is the error-detecting checksum built into common file formats, so this is useful for verifying data integrity, comparing two pieces of text, or matching a checksum produced by another tool.
How it works
The generator uses the standard IEEE 802.3 polynomial (0xEDB88820) — the same CRC-32 used by zip, gzip and PNG. It precomputes a 256-entry lookup table from the polynomial, encodes your text to UTF-8 bytes, then runs the table-driven algorithm: starting from 0xFFFFFFFF, each byte updates the running value via crc = (crc >>> 8) XOR table[(crc XOR byte) & 0xFF], and the final value is XORed with 0xFFFFFFFF. This matches the output of standard CRC-32 libraries.
Reference examples
| Input | CRC-32 (hex) | Notes |
|---|---|---|
hello | 3495352b | Well-known reference value |
Hello | f7d18982 | Case-sensitive — completely different result |
| (empty string) | 00000000 | Empty input |
The text hello (lowercase) produces 3495352b — a widely used reference value to confirm a CRC-32 implementation is working correctly. Note that CRC-32 is case-sensitive: hello and Hello produce completely different checksums because they differ at the first byte.
What CRC-32 is good for
CRC-32 is designed to detect accidental data corruption — bit flips, truncated transmissions, partial writes, and storage errors. It is built into several widely used formats for exactly this purpose:
- ZIP files store a CRC-32 of each entry; extraction tools verify it after decompression.
- PNG images include a CRC-32 at the end of each data chunk to verify chunk integrity.
- gzip appends a CRC-32 of the original uncompressed data so the decompressor can confirm correct reconstruction.
- Ethernet frames end with a Frame Check Sequence that is a CRC-32 over the frame contents.
When you download a file and the provider publishes a CRC-32 alongside it, you compute the same checksum on your downloaded copy and compare. A match means the data arrived intact; a mismatch means something was corrupted in transit or the file was altered.
What CRC-32 is not good for
CRC-32 is not a cryptographic hash and should never be used for security purposes:
- It is straightforward to find two different inputs that produce the same CRC-32 (a collision), which means an attacker can modify a file while keeping the checksum unchanged.
- At 32 bits, there are only about 4 billion possible values — not enough for collision resistance at any meaningful scale.
- It has no secret component, so it cannot authenticate who produced the checksum.
For integrity against intentional tampering, use SHA-256. For passwords, use bcrypt, Argon2, or scrypt. For message authentication codes, use HMAC-SHA-256.
Comparing text quickly with CRC-32
A practical development use of CRC-32 is confirming that two text strings or two file versions are identical without transmitting both copies in full. If the CRC-32 values match, the inputs are almost certainly identical; if they differ, the inputs definitely differ. This is a common sanity check in data pipelines, ETL jobs, and configuration management.
Note that encoding matters: this tool encodes text as UTF-8 bytes before computing. If you are comparing against a CRC-32 from another source, confirm it also uses UTF-8 and that both inputs have identical whitespace and line endings (CRLF vs LF produces different checksums and is a common source of unexpected mismatches).
Everything is computed in pure JavaScript in your browser; nothing is uploaded.