CRC32 Checksum Generator

What this tool is used for

• Checking a value against one stored in a ZIP or PNG structure, both of which use CRC32 internally.
• Detecting accidental corruption in a transfer where speed matters more than any security property.
• Producing a cheap change-detection key for a cache where an adversary is not in the picture.
• Reproducing a checksum from an embedded protocol that specifies CRC32.
• Comparing polynomial variants when a value from another tool refuses to match.

Frequently Asked Questions

Is CRC32 a hash function?

Not a cryptographic one. It is an error-*detecting* code: it reliably catches accidental corruption — flipped bits, a truncated transfer — and offers no resistance at all to deliberate tampering. Anyone can construct a different file with the same CRC in moments.

Which polynomial does it use?

The IEEE 802.3 polynomial, written as 0xEDB88320 in its reversed form. That is the variant used by ZIP, gzip, PNG and Ethernet, which is why the value here matches what `unzip -v` or a PNG chunk reports. CRC-32C (Castagnoli) is a different polynomial and gives different numbers.

Why do two tools give me different CRC32 values?

Because "CRC32" names a family. The polynomial, the initial value, whether input and output bits are reflected, and the final XOR all vary between implementations. Check the variant before assuming a mismatch means the file changed.

How good is it at catching errors?

Very, within its design: it detects every single-bit error, every double-bit error, any odd number of flipped bits, and any burst of 32 bits or fewer. Beyond that the chance of a random corruption slipping through is roughly one in four billion.

When should I use SHA-256 instead?

Whenever the question is "is this the file I expect" rather than "did the transfer break". Verifying a download against a published checksum, deduplicating content, or anything where an adversary might substitute the file all need a cryptographic hash.

Is CRC32 suitable for detecting deliberate tampering?

No — it is linear, so an attacker can adjust the data to preserve the checksum. It reliably catches accidental corruption, which is the job it was designed for and the only one it should be given.

Common errors and gotchas

• Using it against deliberate tampering. It is trivial to construct a different input with the same checksum.
• Comparing values across tools that use different polynomials or bit orders, then reading the mismatch as corruption.
• Assuming it is a hash function. It is an error-detecting code with none of the properties a hash promises.
• Overlooking whether the implementation reflects input and output, which changes the result entirely.
• Expecting 32 bits to be enough for deduplication at scale, where collisions arrive far sooner than intuition suggests.