Compute a file's MD5, SHA-1, SHA-256, SHA-384 or SHA-512 and compare it against a published checksum. Your file never leaves your browser.
Drop a file here, or click to choose one
Nothing is uploaded — hashing happens in this tab
The current default for download verification. Use this unless the publisher listed something else.
Choose a file and the digest appears here.
Paste the hash from the download page. Case and surrounding whitespace do not matter.
Drop it on the page or click to browse. It is read locally — nothing is uploaded, which matters because a verifier that sends your file somewhere has undermined the reason you were verifying it.
It is usually written next to the hash: SHA-256 most often now, MD5 on older projects. If the page only gives you a bare hex string, paste it in the compare box and the tool identifies the algorithm from its length.
Case and surrounding whitespace are ignored, so you can copy straight from a release page without cleaning it up. If the pasted hash length does not match the algorithm selected, the tool says so and offers to switch.
A match means the file is byte-for-byte what produced that checksum. A mismatch means either you picked the wrong algorithm, or the download is incomplete or altered — try downloading again from the original source before assuming the worst.
This is a correctness requirement, not a privacy nicety. Uploading a file to a third party in order to confirm it has not been tampered with introduces exactly the risk you were trying to rule out.
MD5, SHA-1, SHA-256, SHA-384 and SHA-512. MD5 is not part of WebCrypto, so it is our own implementation — verified against the RFC 1321 test vectors, because a hand-written hash without those checks is worthless.
Paste a bare hex string and the digest length gives away the algorithm: 32 characters is MD5, 40 SHA-1, 64 SHA-256, 96 SHA-384, 128 SHA-512.
The MD5 path processes 8 MB at a time and never holds the whole file, so size is not a limit. The SHA variants go through WebCrypto, which requires the complete file in memory — the tool warns you before that becomes a problem instead of failing silently.
Hashes get published uppercase, lowercase, and with line breaks in the middle. All of that is normalised before comparing, so a genuine match is never reported as a mismatch because of formatting.
A match confirms integrity — the bytes are unchanged. Whether it proves authenticity depends on the algorithm and on how you obtained the expected hash, and the page says so rather than implying more than a checksum can deliver.
The everyday case is a download that matters: an OS image, an installer, a database dump, a firmware file. The publisher lists a checksum next to the link precisely so you can confirm the bytes you received are the bytes they released. A truncated download or a corrupted transfer produces a different hash, and finding that out now is much cheaper than finding out while installing.
It also settles the question of whether two files are identical without opening either. Same hash, same bytes — which is useful for confirming a backup copy matches its source, that a transfer to another machine completed intact, or that two similarly-named archives are actually duplicates before deleting one.
There is an important limit worth being precise about. A checksum published on the same page as the download only protects against accidental corruption: anyone who could alter the file could alter the listed hash alongside it. To get an authenticity guarantee you need the expected hash from an independent channel, or a cryptographic signature, which is a different mechanism. Verifying the checksum is still worth doing — just be clear it is answering "did this arrive intact", not "is this genuine".
And on algorithm choice: if a project still publishes only MD5, use it. A matching MD5 is strong evidence against accidental corruption, which is the failure mode that actually happens to downloads. Its weakness is against a deliberately constructed collision, which is a different threat and not the one a broken download represents.
Hashes are frequently published as a bare hex string with no label. The character count tells you which algorithm produced it — there is no overlap between these five.
| Algorithm | Hex characters | Digest bits | Use it for |
|---|---|---|---|
| MD5 | 32 | 128 | Accidental corruption only — do not rely on it for authenticity |
| SHA-1 | 40 | 160 | Legacy verification; collision attacks are practical |
| SHA-256 | 64 | 256 | The current default for download verification |
| SHA-384 | 96 | 384 | Truncated SHA-512; seen on some larger releases |
| SHA-512 | 128 | 512 | Often faster than SHA-256 on 64-bit hardware |
A digest is always the same length regardless of file size — hashing a 4 KB text file and a 40 GB disk image with SHA-256 both give 64 hex characters. If your string is a different length from all of the above, it is probably not one of these (base64-encoded digests and Git object IDs both look similar but are not the same thing).
Select the file, leave the algorithm on SHA-256, and paste the published hash into the compare box. The tool computes the digest locally and tells you whether the two match. It is the same operation as `sha256sum` on Linux, `shasum -a 256` on macOS or `Get-FileHash` in PowerShell — just without a terminal.
No. Hashing runs in your browser using WebCrypto for the SHA variants and a local implementation for MD5. There is no server involved, which is deliberate: a tool that asks you to upload a file to prove it has not been tampered with is asking you to accept exactly the risk you were checking for. It also means the tool keeps working with your connection off.
In order of likelihood: you are using a different algorithm than the publisher (an MD5 will never match a SHA-256), the download did not complete, or you hashed the wrong file — a browser that renamed a duplicate to "file(1).iso" is a common culprit. If the algorithm is right and the file is complete, download again from the original source. A persistent mismatch on a fresh download is worth taking seriously.
For detecting accidental corruption, yes — and that is what a download checksum is for. MD5 is broken against deliberate collisions: it is possible to construct two different files with the same MD5, and that has been demonstrated. So a matching MD5 tells you the file was not corrupted in transit; it does not prove nobody substituted it on purpose. Prefer SHA-256 when the publisher offers both.
MD5 has no practical limit — it processes 8 MB at a time and never holds the whole file, so a multi-gigabyte image is fine. The SHA variants use WebCrypto’s digest function, which takes one complete buffer and has no incremental mode, so the entire file has to fit in the tab’s memory. That works comfortably for a few hundred megabytes and gets unreliable well before it becomes impossible; the tool warns you above 512 MB rather than crashing.
It means the file is unaltered relative to whatever produced that hash — no more. If you took the expected hash from the same page you took the download from, then anyone able to replace the file could also replace the hash, so the check confirms integrity rather than authenticity. For an authenticity guarantee you want a cryptographic signature, or the expected hash from an independent source. Verifying is still worthwhile; just do not read more into a match than it says.
Yes — hash the first, copy the digest, then hash the second and paste the first digest into the compare box. Identical digests mean byte-identical files. This is a reliable way to confirm a copy or a transfer completed intact without opening either file, and it works for any file type.