Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
File checksum
Drop a file and get its digest. Paste the value published by whoever you downloaded it from and the page tells you whether they match. All of it happens on your own machine, which for this particular tool is not a preference but the only version that makes sense.
Where it runs
Any file is read in the browser. Nothing is uploaded.
No queue, no account
It starts the moment you drop the file, and it never asks who you are.
No watermark
What comes out is the file you made, with nothing added to it.
How it works
- Drop the file onto the box above, or press it to choose one.
- The digests are computed on your machine — nothing is sent anywhere.
- Paste the published checksum into the comparison box if you have one.
- A match is confirmed; a mismatch is stated plainly.
Why uploading a file to check it is self-defeating
The point of a checksum is to establish that a file is exactly what its publisher intended — that nothing was corrupted in transit and nothing was substituted. Sending that file to a third party in order to find out reintroduces exactly the party you were trying to rule out. If they returned the wrong digest you would have no way to know.
Computing it locally is the only arrangement where the answer means anything. The digest is produced by your browser using the cryptography built into it, which is the same code your browser uses for HTTPS.
What a checksum does and does not prove
A matching digest proves the bytes are identical to the ones the publisher hashed. That covers a truncated download, a corrupted copy and a substituted file. It is a strong guarantee and a narrow one.
What it does not prove is that the publisher is trustworthy, or that the page you copied the expected value from was not itself tampered with. If an attacker can change the download they can usually change the checksum printed beside it, which is why serious projects sign their releases as well. A checksum answers "did I get what that page offered", not "was that page honest".
Why MD5 is not offered
MD5 has been broken for collision resistance since 2004, and the cryptography built into browsers deliberately declines to implement it. That is a defensible decision and an inconvenient one, because a good many older projects still publish only an MD5.
SHA-1 is here despite having its own collision weakness, because comparing against a published value is the whole use and a great many pages still publish one. It is marked as legacy. If a project publishes only MD5, that is worth noticing about the project.
File checksum: common questions
Is the file uploaded to compute the hash?
No, and for this tool that is the entire point. Sending a file to a stranger in order to verify it reintroduces exactly the party you were checking against. The digest is computed by your own browser.
Which algorithm should I use?
SHA-256 unless the page you are comparing against publishes something else. SHA-512 is longer without being meaningfully more secure for this purpose, and SHA-1 is there because plenty of download pages still list one.
Why is there no MD5?
The cryptography built into browsers does not provide it, deliberately — MD5 has been broken for collision resistance since 2004. We would have to hand-write a broken hash to offer it, and a project publishing only MD5 is telling you something worth noticing.
The checksums do not match. What does that mean?
Most often an interrupted or corrupted download, and downloading again fixes it. It can also mean you compared against the wrong file or the wrong algorithm. Rarely, it means the file is not the one the publisher released — in which case do not run it.
Is there a size limit?
The file has to fit in memory, because the cryptography API takes a buffer rather than a stream. Very large files may fail on a phone and are usually fine on a desktop.