ALL DEVELOPER TOOLS56
File Checksum
File Checksum Verifier — Match a Published Hash
Drop a download, paste the checksum from the release page, and see which algorithm matched — or that none did.
About File Checksum
A checksum is the cheapest way to tell whether the file that landed on your disk is the file the publisher meant to send. A mirror can be stale, a proxy can rewrite, a transfer can stop at 99 percent, and none of those announce themselves: the archive opens, the installer runs, and something is subtly wrong. This tool computes MD5, SHA-1, SHA-256 and SHA-512 for every file you drop, in a background worker so the tab keeps painting, and compares all four against whatever you paste into the expected-checksum box. It reads that paste as the release page wrote it: a bare digest, the two-space sha256sum form with a filename after it, the BSD parenthesised form, an OCI sha256: prefix, or an entire SHA256SUMS file, in which case each file is matched to the line that names it. The algorithm is worked out from the digest's length, and a paste a character short is refused rather than truncated to fit. The verdict names the algorithm that matched, or says plainly that none of them did. You can also save the digests back out as a coreutils-format sums file.
Questions
The checksum on the site is in capitals and mine came out lowercase.
Hexadecimal has no case, so those are the same number. Both sides are lower-cased before they are compared — the digest you pasted and the four this page computed — so a match is reported whichever way either was written. What is not the same is a digest with a character missing. A paste that is 63 or 65 hex characters long is refused outright rather than compared against its first 32 or 40, because a truncated paste that quietly reported NO MATCH would send you off to re-download a file that was fine.
How is this different from the hash generator?
The hash generator computes digests. This page compares them, which is a different job with different ways to go wrong. You paste the line exactly as the release page printed it — a bare digest, the two-space sha256sum form, the BSD SHA256 (file) = form, an OCI sha256: prefix, or a whole SHA256SUMS file — and it works out the algorithm from the digest's length, compares every one of the four digests it computed, and states which matched. Drop several files at once and each is matched to the sums line that names it, so a directory of downloads is one operation.
It says MATCH. Does that mean the download is safe to run?
It means the bytes on your disk are the bytes that checksum was taken from: nothing was corrupted in transit and no mirror served you something else. It does not mean the publisher is trustworthy, and it does not mean the checksum itself is genuine — whoever can replace a download can usually also edit the page listing its hash, and then the two change together. A signature you can verify against a key you already had is the stronger check. This is the fast one, and it catches the failure that actually happens most often, which is a bad transfer.
I pasted a whole SHA256SUMS file and it says my file is not in the list.
With more than one line pasted, each dropped file is matched by name, because the filename is the only thing in a sums file that says which line applies. Directory prefixes are stripped, so a line reading ./dists/ubuntu.iso matches a file called ubuntu.iso, and a case-insensitive match is tried as well. What will not match is a file your browser renamed on download — ubuntu(1).iso, say. Rename it back, or delete every line but the one you want and paste that single digest, which is compared against whatever you drop regardless of its name.
Can I check a 4 GB ISO?
Yes. Each file is hashed as it is read — the digests are fed in chunks off the file stream, so nothing is ever held in memory whole and there is no size at which the read fails. This was not true before September 2026: the file used to be read into one allocation first, browsers hand out roughly 2 GB in a single piece, and a 4 GB ISO could not be opened at all. What a very large file costs now is time rather than failure. All four digests are computed in JavaScript at roughly 40 MB a second together, measured in the browser, so a 4 GB image takes a couple of minutes with a progress bar, and the tab stays responsive because the work happens in a worker.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.