File hash checker — verify a download’s checksum
Hash any file with SHA-256, SHA-512, SHA-1 or MD5 and compare it against a published checksum. Streams multi-gigabyte files without uploading a byte.
- Runs in your browser
- Files are never uploaded
- Free, no account
The file never leaves your device. It is read straight off your disk in 4 MB slices and hashed in this tab, so a 40 GB disk image works the same as a 40 KB text file — and none of it is uploaded. That is also why this is the only honest way to verify a download: an upload-based checker would have to receive the very file whose integrity you are trying to prove.
How to verify a download's checksum
- Drop the downloaded file onto the panel above. Any size and any type. The file is read from your disk in slices, never uploaded.
- Paste the checksum the publisher gave you. A bare hex string, a whole
sha256sumline, a BSD-styleSHA256 (file) = …line, or a colon-separated fingerprint all work. The algorithm is detected from the digest length and enabled automatically. - Wait for the pass to finish. Throughput and progress are shown as it goes, and you can cancel at any point.
- Read the verdict. A match means the file on your disk is byte-for-byte the file the publisher hashed. A mismatch means it is not — do not open it.
Why an upload-based checksum tool is the wrong idea
The point of verifying a checksum is to establish that a file you do not fully trust is genuine. Uploading that file to a website inverts the whole exercise: you hand the suspicious bytes to a third party and then trust their word about them. You also pay to upload potentially gigabytes, and you have no way of knowing what happens to the file afterwards.
Verification only means anything where the file already is. This page reads the file directly from your disk with the File API, hashes it locally, and makes no network requests at all after it loads — you can confirm that in your browser's network panel while a 10 GB image is being processed.
Which algorithm should you use?
| Algorithm | Digest size | Hex characters | Status |
|---|---|---|---|
| MD5 | 128 bits | 32 | Broken for security. Collisions are trivial to construct. Fine for spotting corruption. |
| SHA-1 | 160 bits | 40 | Broken since the 2017 SHAttered collision. Legacy checksums only. |
| SHA-256 | 256 bits | 64 | The current default for release checksums, signatures and integrity checks. |
| SHA-512 | 512 bits | 128 | SHA-2 with 64-bit words. No stronger in practice, often faster on 64-bit CPUs. |
The distinction that matters is between accidental and deliberate change. For catching a download that got truncated by a flaky connection, MD5 is perfectly adequate — a corrupted file will not produce a matching digest by chance. For proving that nobody swapped the file for a malicious one, MD5 and SHA-1 are useless: an attacker who controls the file can construct a different file with the same digest. Use SHA-256 whenever the publisher offers it, and treat a project that only publishes MD5 as a mild warning sign.
A checksum does not prove authenticity on its own
If the checksum sits on the same web page as the download link, an attacker who can replace the file can also replace the checksum. Checksums protect against corruption and against a compromised mirror; they only protect against tampering when you get the digest from an independent source — a signed release file, the project's signing key, a different domain, or a copy you saved earlier.
Hashing very large files in a browser
The browser's native crypto.subtle.digest is fast but has no streaming interface:
it wants the whole input in memory at once, which rules out anything bigger than a couple of
gigabytes. This tool therefore uses native digests for small files and switches to its own
incremental implementations of MD5, SHA-1, SHA-256 and SHA-512 for large ones, feeding them 4 MB
at a time and yielding to the browser between slices so the page stays responsive.
Peak memory stays in the low megabytes regardless of file size, so the practical limit is how fast your disk can be read rather than how much RAM you have. The implementations are checked against the standard FIPS 180-4 and RFC 1321 test vectors, including the awkward cases around block and padding boundaries.
The checksums do not match — now what?
- Check you are comparing the right algorithm. A SHA-256 digest will never match an MD5 one. The tool detects this from the length, but a publisher listing several files can make it easy to grab the wrong line.
- Check you have the right file. Different architectures, editions and point
releases have different checksums, and browsers sometimes append
(1)to a re-downloaded file rather than replacing it. - Download it again, ideally from a different mirror. Most mismatches are interrupted or truncated downloads, and a second attempt fixes them.
- If it still does not match, stop. Do not run the installer to "see what happens". Report it to the project, and get the file from the canonical source.
Command-line equivalents
Everything here matches what your operating system's own tools produce, so you can cross-check:
sha256sum ubuntu-24.04.iso # Linux
shasum -a 256 ubuntu-24.04.iso # macOS
certutil -hashfile ubuntu.iso SHA256 # Windows
Get-FileHash ubuntu.iso -Algorithm SHA256 # PowerShell The digests are identical — a hash function has exactly one correct answer for a given set of bytes. This page simply saves you from remembering which of those four commands your current machine wants.
Questions
Is there a file size limit?
No. The file is read from disk in 4 MB slices and folded into the running hash, so memory use stays flat whether the file is 40 KB or 40 GB. The only limit is how fast your disk can be read; the panel shows throughput as it goes and you can cancel at any point.
Why does an online checksum tool that uploads the file make no sense?
Because you would be handing the very file whose integrity you doubt to a third party, and then trusting their answer about it. Verification only means something if it happens where the file already is. Here the bytes never leave your machine — this page makes no network requests after it loads.
How do I paste the expected checksum?
Any common form works. A bare hex string, a full sha256sum line such as "9fdc… ubuntu.iso", a BSD-style "SHA256 (file) = 9fdc…" line, or a colon-separated fingerprint. The algorithm is detected from the digest length — 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256 and 128 is SHA-512 — and that algorithm is enabled automatically.
The checksums do not match. What should I do?
Do not open the file. A mismatch means the bytes on your disk are not the bytes the publisher hashed: an interrupted or corrupted download, a mirror serving an older build, or in the worst case a tampered file. Download it again from the original source and check it again before you run it.
Should I trust an MD5 or SHA-1 checksum?
For catching an accidentally corrupted download, either is fine. For proving that nobody tampered with a file, neither is: practical collision attacks exist against MD5 and SHA-1, so an attacker who controls the file can produce a different one with the same digest. Prefer SHA-256 whenever the publisher offers it.