File Checksum Verifier
Compute CRC-32 and SHA checksums for a file and compare them against a published value, entirely in your browser with no upload.
Drop a file to compute its checksums, then paste the checksum the publisher listed to confirm the download is intact.
Compare
CRC-32 proves something SHA-256 only makes likely
The CRC-32 above is not a weak hash. It is an error-detecting code, and within its design range it is not probabilistic at all — it catches certain kinds of damage every single time, by construction. Taking the 43-byte message “The quick brown fox jumps over the lazy dog” and flipping bits in it:
| Corruption | Cases tested | Missed |
|---|---|---|
| Every single-bit flip | 344 | 0 |
| Every two-bit flip | 58,996 | 0 |
| Bursts up to 32 bits | 1,515 | 0 |
Not “detected with high probability”. Detected. CRC-32 catches all one- and two-bit errors and all burst errors up to 32 bits long — the same 32 as its own width, which is not a coincidence — for any message whatsoever. That is the property it was built for, and it is why CRCs sit inside Ethernet frames and ZIP archives rather than a hash function. SHA-256 makes no such promise: a two-bit change will change it with overwhelming probability, but nothing in the design forbids a collision. The value shown for “123456789” is cbf43926, the published conformance figure, so this is the same CRC-32 those formats use rather than a lookalike.
And SHA-256 proves something CRC-32 cannot approximate
The moment somebody is choosing the corruption on purpose, the CRC is over. It is 32 bits, so there are about 4.3 billion of them, and the birthday bound says a repeat turns up after roughly the square root of that. Feeding random eight-byte strings through this exact CRC-32, twelve runs found their first collision after:
| Run | Values hashed before a collision |
|---|---|
| 1 | 13,195 |
| 2 | 54,414 |
| 3 | 65,383 |
| 4 | 66,637 |
| 5 | 71,177 |
| 6 | 71,484 |
| 7 | 84,629 |
| 8 | 87,501 |
| 9 | 93,571 |
| 10 | 114,256 |
| 11 | 140,896 |
| 12 | 187,987 |
Median 78,056.5, against a theoretical median of 77,163 — agreement to 1.2%. The mean is higher at 82,137, because the distribution has a long right tail. The spread is the part people get wrong: the slowest run took 14.2 times as long as the fastest. There is no threshold at which collisions begin. There is a wide distribution centred on about eighty thousand, and eighty thousand files is not a large number of files.
SHA-256's equivalent figure is 2128. That is 112 doublings past the CRC's, which is not a ratio anyone has an intuition for — no sequence of events in the physical universe produces that many hashes.
The CRC is linear, which is worse than being short
Being findable by accident is one problem. Being solvable is another. CRC-32 is linear over exclusive-or: for any three equal-length messages, CRC(x XOR y XOR z) equals CRC(x) XOR CRC(y) XOR CRC(z). Checked over 2,000 triples, it held exactly 2,000 times out of 2,000. So an attacker does not search for a matching CRC. They solve for one. Given a file to alter and the checksum it has to keep, the bytes to change are a linear system in 32 unknowns, and that is not a challenge. A cryptographic hash is specifically designed not to have this property.
| Algorithm | Bits | What it is for | Survives a deliberate attacker |
|---|---|---|---|
| CRC-32 | 32 | Accidental corruption | no |
| SHA-1 | 160 | Legacy identifiers | no |
| SHA-256 | 256 | Verifying a download | yes |
| SHA-384 | 384 | Verifying a download | yes |
| SHA-512 | 512 | Verifying a download | yes |
Which is why both are worth printing and why MD5 is left out. Check the CRC-32 to know your download did not get mangled in transit — it will tell you that better than SHA-256 will. Check the SHA-256 to know it is the file the publisher actually built. SHA-1 is here because older projects still publish it, not because it should be trusted for the second job.
How to use
- Choose the file to check.
- Wait for the checksum to compute.
- Paste the published value to compare.
- Get the published value from a source you trust.
Frequently asked questions
Does my file get uploaded?
No. The file is read and hashed in your browser, so it never leaves your machine. That is the main reason to check a download locally rather than with an online service that requires an upload.
What does a matching checksum prove?
That the file you have is byte-identical to the one whose checksum was published. It proves nothing about whether that original file was trustworthy — if an attacker replaced both the file and the published checksum, they match perfectly. The value of the check depends entirely on the checksum coming from a source the attacker did not control.
What is the difference between CRC-32 and SHA-256?
Purpose. CRC-32 detects accidental corruption — a flipped bit in transmission or storage — and is fast and small. It offers no security at all, since a matching CRC is trivial to forge. SHA-256 is a cryptographic hash designed to make deliberate forgery infeasible.
Which should I use?
SHA-256 for verifying software downloads or anything where tampering matters. CRC-32 for detecting corruption in archives and transfers, where it is what many formats already use internally. Choosing CRC for a security check is a meaningful mistake.
Why do some projects publish a signature as well?
Because a signature ties the checksum to an identity. Anyone can publish a hash; only the holder of a private key can produce a valid signature over it. Verifying the signature is what turns 'this file matches what the page said' into 'this file came from the project'.
Why is hashing a large file slow?
Because every byte must be read and processed. Speed is limited mainly by disk and by the browser reading the file in chunks. A multi-gigabyte file takes real time, and CRC-32 will be noticeably faster than SHA-256 for the same input.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.