How to Verify a File Hash: Compare a Checksum Before You Trust a Download
A practical guide to verifying downloads with a checksum. Compare the computed SHA-256 or MD5 against the publisher's value, and learn what a match really proves.
How to Verify a File Hash: Compare a Checksum Before You Trust a Download
You clicked download. The progress bar filled up. The file landed in your Downloads folder. The question nobody answers for you is: did the right bytes arrive? A 4 GB installer that lost a few hundred bytes to a flaky connection looks exactly like a clean one in the file browser. Same name, same icon, roughly the same size. The only honest way to tell them apart is a checksum.
A checksum is a short fingerprint computed from every byte in the file. The publisher computes it once, prints it on the release page, and you compute it again on your machine. If the two strings match character for character, the file you have is byte-for-byte the file they shipped. If they differ even slightly, something changed in transit, on disk, or in someone's hands.
What a checksum actually is
A checksum is the output of a hash function such as SHA-256, SHA-512, or the older MD5. You feed in a file of any size and the function spits out a fixed-length string of hexadecimal: 64 characters for SHA-256, 32 for MD5. The same input always produces the same output, so the publisher and you, running the same algorithm on the same bytes, will land on the same digest.
The property that makes this useful is the avalanche effect. Change one byte anywhere in a multi-gigabyte file and the entire hash changes. Flip a single bit and you do not get a hash that is "mostly the same" with one character off. You get a completely different 64-character string with no visible relationship to the original. This is the whole point: there is no partial credit. The match is binary. Either every byte is intact, or it is not, and the hash tells you which without ambiguity.
That is also why you compare the strings exactly, not approximately. When you verify a file, you compute its hash and line it up against the publisher's published value digit by digit. A single mismatched character means the file is not the one that was published. A full match means the file is intact. There is no "close enough" reading of a checksum.
A worked example: checking a downloaded ISO
Say you pulled down a Linux ISO and the release page lists this SHA-256:
9f2c7e10a4b3d6e8c1f0a2b5d8e7c4f1
0b3a6d9e2c5f8a1b4d7e0c3f6a9b2d5e(Published digests are one continuous 64-character line; it is wrapped here only to fit the page.)
Open the File Checksum Compare tool, paste that value into the expected field, and select your downloaded ISO. The tool reads the file in your browser, computes its SHA-256, and shows you both strings side by side with a clear MATCH or MISMATCH verdict. You do not have to eyeball 64 hex characters yourself, which is exactly the kind of task where human eyes skip a transposed pair and call it good.
If you would rather hash text or smaller inputs and read the raw digest, the MD5 and SHA hash generator gives you the computed value directly so you can copy it wherever you need it.
When the verdict reads MATCH, your local ISO is identical to the one the maintainers built. When it reads MISMATCH, stop. The download is incomplete, corrupted, or substituted, and burning it to a USB stick or running the installer is exactly what you should not do next.
Integrity versus security: two different questions
It is tempting to treat a green MATCH as a stamp of safety. It is not, and the distinction matters.
A checksum answers an integrity question: are these the same bytes the publisher released? It does not answer a security question: is the publisher trustworthy, and is the published digest itself genuine? If an attacker compromises a download server, they can replace both the file and the checksum printed next to it. Your verification would pass cleanly because you are comparing the tampered file against the tampered digest. The math is correct; the trust assumption is broken.
This is why the published value has to come from a channel you trust independently of the file. A SHA-256 listed on an HTTPS release page, signed in a GPG-verified manifest, or cross-checked against a second mirror carries real weight. A hash pasted into a forum comment next to a download link carries almost none. The strongest setups pair the checksum with a cryptographic signature, so you verify not just "these bytes are intact" but "these bytes were signed by the key I expect." For tamper detection from a trusted source, a checksum is excellent. As a virus scan, it is meaningless. A perfectly intact file can still be malware.
Why local hashing is the right default
The first time I had to verify a vendor's data export for a compliance handoff, I genuinely worried about uploading a confidential archive to some random "online hash" site just to check it. That instinct was correct. You should never have to ship a file to a server to learn its fingerprint.
Hashing is a local computation. The algorithm runs entirely on bytes you already have, so there is no reason for the file to leave your machine. Browser-based tools that hash with the Web Crypto API read the file straight from disk, compute the digest in memory, and compare it on the page. Nothing uploads. For evidence packages, financial exports, firmware, or anything under NDA, that is not a nice-to-have. It is the difference between a verification step you can run and one your security policy forbids.
Local hashing is also faster and works offline. Once the page is loaded you can pull the network cable and still verify a 6 GB image, because every byte the function needs is sitting on your own drive.
A short checklist for trustworthy verification
- Get the expected digest from a channel you trust on its own, not from beside the download link.
- Match the algorithm. A SHA-256 file compared against a SHA-512 value will always mismatch, and the mismatch tells you nothing about integrity.
- Compare the full string, not the first and last few characters. Tools that diff all 64 characters for you remove the most common human error.
- Read MISMATCH as a stop sign. Re-download from the source before you do anything else with the file.
- Remember the boundary: a match proves the bytes are intact, not that the file is safe to run.
Verifying a checksum takes about ten seconds and rules out a whole class of silent failures, from a download that dropped packets to an archive someone quietly swapped. It will not make a dangerous file safe, but it will tell you, with no room for interpretation, whether the file in front of you is the one that was actually published.
Made by Toolora · Updated 2026-06-13