File Checksum Verifier

Drop a file in and compare its checksum against the value you were given, in any of the formats publishers use. The file never leaves your browser.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Drop files, or choose them

Up to 512 MB each, 20 at a time. Hashed in your browser.

Algorithms SHA-256 SHA-512 SHA-1 MD5

Expected checksum (optional) Case and spacing do not matter. A full coreutils or BSD line is read correctly.

What a matching checksum actually proves

That the file you have is byte-for-byte the file whose checksum was published. That is worth a lot: it catches truncated downloads, corrupted transfers, disk errors and the wrong file entirely. It is the everyday use and it works.

What it does not prove is that nobody tampered with the file - and the reason is more mundane than cryptography. If an attacker can replace the download, they can usually replace the checksum published beside it. A hash on the same page as the file it describes is an integrity check against accident, not against an adversary. Only a signature, verified against a key you obtained separately, covers the second case.

MD5 and SHA-1 are here, with a caveat attached

Both are broken against deliberate collisions - an attacker with resources can produce two different files with the same MD5, and has been able to for years. SHA-1 fell in 2017.

They are offered anyway, because the checksum published next to a download is still often MD5, and a tool that cannot check the value you were actually given is not much use. When a match is found against one of them, the result says what that match means and what it does not. Web Crypto deliberately omits MD5, so it is implemented here directly - and tested against RFC 1321's own vectors, because a checksum tool that computes the wrong checksum is worse than none at all.

When it does not match

The most common causes, in order: comparing against the wrong algorithm, downloading a different file from the one the checksum describes, and an incomplete download. Tampering is the rarest and worth ruling out last rather than first. The result explains which of these to check.

Nothing is uploaded

Files are read with the browser's FileReader and hashed locally. That is not a nicety - the files worth checksumming are installers, disk images, archives and backups, and uploading one to check a hash would be both slow and absurd.

Frequently asked questions

Which algorithm should I use?

Whichever the publisher gave you - a checksum only means something compared against the one that was published. If you have a choice, SHA-256. If the only value offered is MD5, use it and understand it as a corruption check rather than a tamper check.

Can I check a really large file?

Up to 512 MB here. The browser has to hold the whole file in memory to hash it, so beyond that the tab is likely to be killed rather than give an answer. For a DVD image use sha256sum on Linux or macOS, or certutil -hashfile on Windows.

Why do two tools give different checksums for the same file?

Almost always different algorithms. Check the length: 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256. If the algorithm matches and the values differ, the files genuinely differ.

Is the file uploaded?

No. It is read locally and hashed with the browser's own crypto. You can confirm it in the network tab.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.