Checksum Verifier
The file is read in this page and never uploaded. Nothing in either box below reaches the address bar — a shared link carries which example is loaded and nothing else.
Verdict
Hashing
Reading the input and computing all four digests. A large file is read in one pass, so this takes as long as your disk needs and no longer.
d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592— 4 digests computed, none of that shapeHow this was worked out
- Bytes read43 bytes of UTF-8 from the text box
- Digests computedall 4 of them — SHA-1, SHA-256, SHA-384, SHA-512 — by crypto.subtle on this machine
- Published value read asbare format, hex
- Narrowed toSHA-256 — the only one of the four that produces a value of this shape
- Comparedcharacter by character, every character, without stopping at the first difference — see the note below for why that habit matters
The comparison is character by character, every time. It does not stop at the first difference, which for a number printed on a web page changes nothing at all — there is no secret in it to protect. The habit is worth keeping because the identical code comparing an API signature or a session token does leak: an attacker who can measure how long the check took learns how many leading characters were right, and recovers the rest one at a time.
A matching checksum proves the bytes you have are the bytes the number was computed from. It does not prove who computed the number. If the digest was published on the same page as the download, whoever could swap the file could swap the digest beside it, and both would agree. The step that closes that gap is a signature checked against a key you obtained separately — which is why release pages publish a signed checksum file rather than a bare digest, and why gpg --verify is the command that follows this one.
Only the four digests Web Crypto is required to provide are computed here — SHA-1, SHA-256, SHA-384, SHA-512. There is no MD5, because the platform does not offer one and shipping a hand-rolled broken hash for the sake of completeness would be worse than the gap. A published MD5 cannot be checked on this page at all; md5sum is the command for it.
One comparison, four digests, no upload
Choose a file or paste some text and the browser computes its SHA-1, SHA-256, SHA-384 and SHA-512 digests locally, through the same crypto engine a website uses for TLS. Paste the value the download page published and the tool works out which of the four it could be from its length, then compares the two. The file is read from disk into memory and never sent anywhere, so the only real limit is how much your machine can hold.
Because the shape decides the comparison, there is nothing to configure. A 64-character value can only be the SHA-256 line, a 40-character one only SHA-1, and the answer names which digest was used rather than leaving you to check.
The formats it will take
Checksums are published in several conventions and all of them are accepted here. GNU coreutils writes the digest, two spaces and the filename, with an asterisk in place of the second space for binary mode. BSD systems and openssl dgst write the algorithm and the filename first, as SHA256 (file.iso) = followed by the value. Subresource Integrity attributes use base64 after an algorithm name and a hyphen.
A value copied from a web page often arrives wrapped across two lines or in upper case, and both are handled: whitespace is removed and hex is compared without regard to case, since hex is a number and case carries no information in it. Base64 is compared exactly, because there case carries all of it. Where a line names a file, that name is shown but never checked against the digest, since it is not part of what was hashed.
Reading a mismatch
A failed comparison is far more often a mundane problem than an attack. The download stopped early and the file is short; the checksum belongs to a different release, a different architecture or a different image on the same page; or the published value is for an algorithm none of these four covers, such as MD5 or BLAKE2b. Compare the lengths first — 32 characters is MD5 and cannot be checked here at all.
For text rather than files there is a second common cause: what looks like the same string is not the same bytes. A trailing newline, a non-breaking space pasted from a browser, or Windows line endings inside the text all change the digest completely while looking identical on screen.
What a match actually establishes
A match proves the bytes you have are the bytes the digest was computed from. It proves nothing about who computed it. When the digest sits on the same page as the download, anyone able to replace one can replace the other, and the pair will agree perfectly afterwards.
Closing that gap needs a signature verified against a key obtained through some other route — which is why distributions publish a signed checksum file and expect you to run gpg --verify against a keyring you already trust. The checksum then guards against a corrupted transfer, and the signature guards against a substituted file. This tool does the first job only.
Why the comparison takes its time
The comparison here does not stop at the first character that differs. For a number printed on a public web page that changes nothing, since there is no secret in it to leak. It is written that way because the identical code, applied to an API signature or a session token, does leak: an attacker who can measure how long the check ran learns how many leading characters were correct, and recovers the value one character at a time.
Large files, MD5, and what a match proves
Can I verify a 4 GB disk image in a browser tab?
Often yes, though the file is read into memory first, so a very large image on a modest machine may fail. Where it does, the command line tools shipped with your operating system have no such ceiling.
The page publishes an MD5 checksum. Why can I not use it?
Because browsers implement exactly four digest algorithms and MD5 is not among them. Adding it would mean shipping a hand-written copy of a hash function that has been forgeable since 2004, which is not worth doing for completeness.
The page lists SHA-1 and SHA-256 for the same file. Which do I use?
The stronger one, always. SHA-1 remains useful for spotting a corrupted download but a chosen-prefix collision against it was demonstrated in 2020, so it should not be the basis of a decision about whether a file was tampered with.
Is the file I choose uploaded anywhere?
No. The browser reads it from disk into memory, hands the bytes to its own crypto engine and discards them when the tab closes. No request leaves the page at any point in the process.
What is Subresource Integrity?
The integrity attribute on a script or stylesheet tag: a base64 digest the browser checks before it runs the file. If the CDN serves something else, the resource is refused rather than executed — a published checksum, enforced automatically.
Do two different files ever produce the same digest?
For SHA-256 and above, nobody has produced a pair and nobody expects to. For SHA-1 it has been done deliberately, which is why a matching SHA-1 tells you a download completed and not that nobody chose its contents.