Loading Checksum Verifier…
Waiting for a checksum
Paste the value from the download page. The four digests are computed as soon as a file or some text is chosen, so only the comparison is waiting.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.