File hash checker (SHA-256, SHA-1, MD5)
Hash a download and compare it with the publisher's checksum, character by character.
Nothing leaves your browser. This tool does its work on your own machine — there is no upload, no server request, and nothing is stored.
Choose a file, or drop one here
Any size. The file is read from your own disk in blocks and never uploaded.
Comparing by eye is exactly how a mismatch gets missed — the middle of a 64-character string all looks the same. Paste it here and the comparison is done character by character.
What a checksum proves
A hash is a fingerprint of a file's exact bytes. Change one bit anywhere — a single pixel, a single character in a config file, one instruction in an executable — and the hash changes completely and unpredictably. That is what makes it useful: it is not a summary you can partially match, it either agrees or it does not.
So when a publisher lists a SHA-256 next to a download, they are giving you a way to confirm that what arrived is what they built. It catches a corrupted transfer, a mirror serving an altered file, and an attacker who intercepted the download.
The part people skip
A checksum published on the same page as the download only helps against accident. An attacker who can replace the file can replace the number printed beside it. The check becomes meaningful when the hash comes from somewhere the attacker does not control — a signed release file, the project's repository, a package manager's database, or documentation you had before today.
Which algorithm
- SHA-256 — use this unless told otherwise. No practical attack exists against it.
- SHA-1 — broken since 2017. A determined attacker can build two different files with the same SHA-1. Fine for spotting a corrupted download, useless as a defence.
- MD5 — broken far more thoroughly, and collisions can be produced on a laptop in seconds. Still published by plenty of older projects, which is the only reason it is offered here.
If a project publishes only an MD5, treat a match as evidence the download completed properly and nothing more.
How this handles large files
The file is read from disk in blocks and fed through the hash a block at a time, so a four-gigabyte disk image costs a few dozen bytes of memory rather than four gigabytes. All three algorithms here are implemented in the page itself for that reason — the browser's built-in hashing requires the entire file in memory at once.
Common questions
Why check the hash of a download?
Because a file that was tampered with in transit, or served from a mirror that was compromised, is byte-for-byte different from the one the publisher built. The hash is a fingerprint: change one bit anywhere and it changes completely.
Which hash should I use?
SHA-256, unless the publisher listed something else. MD5 and SHA-1 are still offered here because plenty of older projects publish them, but both are broken against a deliberate attacker and should only be used to catch accidental corruption.
Is my file uploaded anywhere?
No. The browser reads the file in chunks from your own disk and hashes it locally. Large files work fine because the whole file is never held in memory at once.