How to verify a download with SHA-256

Run one command on the file you downloaded and compare the result to the digest the publisher listed. If the two strings are identical, your copy is byte-for-byte what they released.

Compare the whole string. Checking that it starts with a3f9 and ends with c21b is not a comparison — those are the characters anyone bothering to forge a digest would keep.

Start with the part that gets skipped, because it decides whether the exercise was worth anything.

If the digest was printed on the same page as the download link, you have proved very little. Anyone able to replace the file could edit the line above it in the same breath. What you have confirmed is that the page is internally consistent, which was not the question.

A digest is worth something when it reaches you by a different route than the file: a signed release note, a distribution’s package index, a repository you already trust, a message from the person who built it. Same page as the download, same trust as the download.

What it does prove, reliably and every time, is that the file arrived intact. A truncated transfer, a proxy that mangled something, a disk that flipped a bit — all caught. That is the everyday use, it is a real one, and it is most of why you would bother.

It says nothing about whether the file is safe. A matching digest on malware confirms you have exactly the malware the publisher shipped.

Most “online SHA-256” tools upload your file to compute it. For a public installer that is merely pointless. For anything you would not email to a stranger it is worse, because you have now handed a third party a copy in order to check a hash.

There is no technical reason for it. Browsers can hash a file locally, reading it from disk in windows so the file is never held whole in memory. Ours does that for SHA-256, SHA-1 and MD5, and you paste the published digest in so the comparison is done for you rather than by eye.

Checked against coreutils on the same 300 MB file, with every network request between choosing the file and the answer appearing recorded:

A checksum tool that returns a plausible but incorrect value is actively harmful. It will tell you a good download is corrupt, and — far worse — it can agree with a published digest while your file differs.

So each implementation is tested against the published vectors from RFC 1321, RFC 3174 and FIPS 180-4. That is table stakes and proves less than it looks: a test suite only tells you something if you have checked it can fail. So each hash was deliberately broken to watch the tests go red.

The sabotage worth showing is MD5’s padding. Every one of these algorithms finishes by appending the message length as a 64-bit field, and swapping its two halves is the kind of mistake that produces output looking exactly like a normal MD5 — right length, right character set, completely wrong:

Nothing about the second value announces itself as broken. Only a test comparing against a known answer catches it, which is the entire argument for having one.

Publishers still list them, so a tool that refuses to compute them just sends you elsewhere. But they are not interchangeable with SHA-256 and it is worth being blunt about which job each one can do.

For detecting accidental corruption — the truncated download, the bad disk — MD5 and SHA-1 are completely adequate. For detecting deliberate tampering, both are broken: MD5 thoroughly and for a long time, SHA-1 in practice as well. If someone might be trying to fool you, the SHA-256 line is the only one that means anything, and a page offering only an MD5 is telling you something about how much attention it pays.

Fifteen seconds, and it works on any tool including this one. Open the page, press F12, switch to the Network tab, then choose your file.

A local tool shows nothing at all while it works. An uploader shows a request the size of your file, and you can watch the bar climb.

The simpler version needs no developer tools: load the page, turn off your network, then use it. Local tools carry on. Uploaders stop.