Last updated October 13, 2026 · Report an error
CRC-32 (Cyclic Redundancy Check, 32-bit) is a fast, widely-used checksum algorithm for detecting accidental data corruption — it's the checksum format built into the ZIP file format, PNG image files, and many network protocols including Ethernet frames. It was designed decades ago specifically to catch the kind of bit-flip errors that occur during storage or transmission, not to provide cryptographic security. Because CRC-32 is cheap to compute and produces a small, fixed-size 32-bit output, it became the default choice for quick integrity checks embedded directly into file formats — every entry in a ZIP archive, for instance, carries its own CRC-32 value that unzip programs verify automatically to make sure the extracted data matches what was originally compressed. This tool computes the CRC-32 checksum of any text input, showing the result in both decimal and hexadecimal, so you can compare it against a checksum reported by another tool regardless of which base that tool displays.
How it works
The text is run through the standard CRC-32 polynomial algorithm (the same one used internally by the ZIP file format, PNG images, and Ethernet), which processes the input byte by byte through a lookup-table-driven division against a fixed 32-bit generator polynomial. The result is a 32-bit checksum value, shown both as a decimal number and as its 8-digit hexadecimal representation, since different tools and file formats conventionally display CRC-32 values in one base or the other.
- Enter text.
- Click Calculate to see your results.
Examples
A known reference value
The text "Hello, World!" (with no trailing newline) produces a fixed, reproducible CRC-32 checksum — running the same exact input through any standard CRC-32 implementation, including this tool, gives the identical result every time.
Detecting a single-character change
Changing just one character in a large block of text — even a single letter — produces a completely different CRC-32 value, which is exactly the corruption-detecting property the algorithm is designed to provide.
Comparing decimal and hex output
A CRC-32 result might display as the decimal number 3510195174 and the hexadecimal value 0xD156A2A6 — these are simply two different ways of writing the exact same 32-bit number.
Who should use it
- Verifying a downloaded file or pasted text matches an expected checksum.
- Learning how ZIP/PNG-style checksums work.
- Quickly detecting whether two versions of a text file differ.
Industry applications
- File compression/archiving
- Network protocols
- Data storage integrity checks
Advantages
- Very fast to compute, even on large inputs.
- Same algorithm used by ZIP and PNG internally, so results are directly comparable to those formats' own stored checksums.
- Small, fixed-size 32-bit output regardless of input length.
Limitations
- Not cryptographically secure — an attacker can deliberately construct a different input with a matching checksum.
- Only 32 bits of output means collisions, while rare by accident, are far more likely than with a 256-bit hash.
Common mistakes to avoid
- Using CRC-32 for password or security-sensitive hashing — it's a checksum for error detection, not a cryptographic hash, and offers no resistance to deliberate tampering.
- Comparing a CRC-32 computed on text that includes an invisible trailing newline against one that doesn't — the two checksums will differ even though the visible text looks identical.
- Assuming a matching CRC-32 guarantees the data is identical for security purposes — for accidental corruption checks this is fine, but it's not a tamper-proof guarantee.
Best practices
- Use CRC-32 to verify a file or message wasn't accidentally corrupted in transit; use a cryptographic hash (SHA-256, etc.) if tamper-resistance against a deliberate attacker matters.
- When comparing checksums between two tools, confirm whether each is reporting decimal or hexadecimal to avoid a false mismatch.
- Double check for exact input (including trailing whitespace/newlines) when a checksum comparison unexpectedly fails.
Tips
- Need a cryptographically secure hash instead? Use the SHA256 or SHA512 Hash Generator.
- If you're comparing against a checksum reported elsewhere, check whether it's shown in decimal or hex first.