How to Verify a Download With a Checksum (and When It Matters)
A checksum takes ten seconds to check and catches things antivirus misses. Here's what MD5, SHA-1 and SHA-256 actually prove about a downloaded file.
Nobody checks checksums. The string sits there under the download button, sixty-four characters of hex that look like a rendering bug, and everyone scrolls past it to click the installer.
Which is fair, mostly. Your download almost certainly arrived fine. But the check costs about ten seconds, and the two occasions it pays for itself are worth understanding, because they are not the ones people assume.
What a hash actually catches
A cryptographic hash reads every byte of a file and produces a fixed-length fingerprint. Flip one bit in a 5 GB disk image and the SHA-256 changes completely. There is no partial credit, no “close enough” reading.
So a matching hash rules out a specific list of problems: a download that stopped early and left you a plausible-looking file, a bad sector on the drive you saved it to, a flaky USB stick, a CDN node serving a stale build. If you have ever burned an ISO that booted to a kernel panic, that was probably a corruption you could have caught in advance.
What it does not tell you is whether the file is safe. A hash is a comparison, not a judgement. Malware has a perfectly valid SHA-256.
The case people miss
In May 2017 someone compromised one of HandBrake’s two download mirrors and swapped the Mac build for a version carrying the Proton trojan. Anyone who happened to be routed to that mirror got a working video encoder and a remote-access backdoor. The project’s advisory pointed users at the checksum, because the compromised mirror hosted the file while the main site still published the real hash. A ten-second comparison would have caught it.
Compare that to Linux Mint in February 2016. The attacker got into the website itself, replaced the ISO link, and edited the published MD5 on the same page. Users dutifully compared the hash to the one on screen, and it matched, because both had come from the attacker.
That is the whole lesson in two stories. A checksum protects you when the file and the hash travel by different routes. It protects you from nothing at all when a single compromised source hands you both. This is also why serious projects sign their SHA256SUMS file with a GPG key: the signature is the thing that ties the hash back to a person rather than a webserver.
Which algorithm to use
Use whichever one the publisher gave you. If they offer several, take SHA-256.
MD5 has been cryptographically dead since 2004 and SHA-1 since 2017, in the sense that both allow an attacker to construct two files sharing a hash. That kills them for anything security-related. It does not kill them for spotting a truncated download, because random corruption will not land on a collision by accident. Plenty of mirrors and firmware archives still publish only MD5, and checking it beats checking nothing.
Doing the check
On Linux: sha256sum file.iso. On macOS: shasum -a 256 file.iso. In PowerShell: Get-FileHash file.iso -Algorithm SHA256. Then compare a long hex string by eye, which is exactly where people get sloppy and glance at the first six characters.
Or drop the file into the File Hash Checker, paste the published hash, and let it do the comparing. It reads the file in 4 MB slices in your browser, so a multi-gigabyte ISO works fine and nothing gets uploaded anywhere. For hashing text rather than files, the Hash Generator covers the same algorithms plus SHA-512.
Next time you grab an ISO, check it. It takes less time than reading this paragraph did.