Checksum calculator
Drop files to see their checksums
Hashed in your browser · the file is never uploaded
A checksum tells you whether the file you have is byte-for-byte the file the publisher released. Compute the hash of your copy, compare it with the one on the download page, and if they match nothing was corrupted or altered in transit. Drop a batch and each file gets its own digest, which is also how you spot duplicates.
How to verify a checksum
The reason this has to run locally is not privacy but logic. Uploading a file to a website so that it can tell you the file is genuine puts the website between you and the answer, if it is compromised, or simply wrong, you learn nothing. Hashing in your own browser removes that step. One limitation to be honest about: a checksum only proves the file matches the value you compared against. If an attacker controls the download page, they control the published hash too. That is what signatures are for, and why security-critical releases are signed rather than merely hashed.
Hashing several files at once answers a different question: which of these are the same file. A digest covers the contents and nothing else, so renaming a file, moving it or touching its timestamp leaves it unchanged, and a repeated digest in the list is a duplicate however the two are named. The size printed beside each row narrows it before the digests do, because two files of different sizes cannot be the same file. CRC-32 is the fastest of the six by a wide margin and fine for a first pass over a folder, though a 32-bit value starts producing accidental matches once you are comparing tens of thousands of files. SHA-256 when the answer has to be certain.
The comparison box reads one file, which is deliberate: a published checksum belongs to a single release, and matching it against a list would only tell you that one of the files was the right one. Drop a single file when you are verifying, and a batch when you are cataloguing.
What people use it for
- Verifying an ISO or installer against the checksum on its download page
- Hashing a folder of files to find duplicates by digest instead of by name
- Reproducing an MD5 that an old release page still quotes
- Checking that a large transfer arrived intact after a flaky connection
- Confirming two backup folders hold byte-identical copies
- Telling apart two images that look the same and were re-saved differently
Questions
Whichever the publisher used. The point is comparing like with like. If several are offered, prefer SHA-256.
Yes. Everything after the hash is ignored, so abc123… ubuntu.iso compares correctly.
Only your device’s memory. Multi-gigabyte ISOs work, though hashing one takes a moment.
Download again. If it still does not match, do not run the file: it is either corrupted or not what the publisher released.
As many as you like. It runs on your device, so the limit is memory and patience.
Drop them all in and look for repeated digests. Files with different sizes can never match, so the size column narrows it quickly.
CRC-32, by a wide margin, and it is adequate for spotting accidental duplicates. Use SHA-256 when you need certainty.
No. The hash covers the contents only. Name, timestamps and folder are not part of it.
With MD5 or SHA-1, deliberately, yes. With SHA-256 it is not something that will happen by accident or by design.
No. The comparison box reads a single file, because a published sum belongs to one release. Drop one file to verify, several to list.
No, and that is the whole point. A checksum verified by a third party is not a verification.
It means it matches what you compared it against. If the site publishing the hash is compromised, so is the hash; use a signature for anything critical.