What CRC32 is for, and what it is not for
CRC32 is a cyclic redundancy check, not a cryptographic hash. It was designed to catch accidental corruption: a flipped bit on a wire, a truncated download, a bad sector in an archive. It is fast, it is only 32 bits long, and it is used exactly where that tradeoff makes sense, inside ZIP and PNG files, in Ethernet frames, and in a great many firmware and archive formats.
What it cannot do is prove that a file was not tampered with. Producing a different file with the same CRC32 is trivial for anyone who wants to, which is why no security process should rely on it. If you are verifying that a download matches what a publisher signed, use the SHA-256 value shown next to it. If you are checking that a file survived a copy intact, CRC32 is the right tool and a perfectly good one.
This calculator shows five digests together because the question people actually arrive with is usually "does this match the number on the page", and the page rarely says which algorithm it used. Comparing against all five removes the guesswork.
- CRC32 catches accidental corruption, not deliberate tampering
- Used inside ZIP, PNG, Ethernet frames, and many firmware formats
- Use SHA-256 when the check is about trust rather than transport
How the calculation runs
Choose a file and it is read into the browser tab as one buffer, then all five digests are computed from that same buffer. SHA-256, SHA-512, and SHA-1 come from the browser built-in cryptography implementation, MD5 comes from a small bundled library, and CRC32 is computed in plain JavaScript with a lookup table built from the standard reflected IEEE polynomial, the same variant ZIP and PNG use.
The output is lowercase hexadecimal throughout. CRC32 appears as exactly eight hex characters, zero-padded on the left, with no leading 0x. That padding matters: a checksum whose value happens to be small is often written elsewhere without leading zeros, and comparing the raw strings would then fail even though the values match.
Every digest has its own copy button. Nothing about the file content is transmitted; the only network request is a usage ping that contains the tool name, not the file or anything derived from it.
Comparing against a known checksum
The comparison field takes a checksum you already have and reports which of the five digests it matched, or that it matched none. That answers the practical question directly rather than making you eyeball two long hex strings and hope your eyes did not skip a character.
The comparison is lenient in useful ways and strict in others. Input is trimmed and lowercased, so a checksum copied in uppercase still matches. For CRC32 specifically, a leading 0x is stripped and the value is padded to eight characters, which covers the common ways CRC32 values get written down. What it does not do is strip internal spaces or a trailing file name, so paste only the hash itself if a checksum file put more on the line.
A no-match result means one of three things: the file is different from the one the checksum came from, the checksum was for an algorithm not covered here, or something got mangled in the copy and paste. Check the last of those first, since it is by far the most common.
- Uppercase input is fine; it is lowercased before comparing
- A leading 0x on a CRC32 value is stripped, and short values are padded to eight digits
- Paste only the hash, not the whole line from a checksum file