How to verify a file checksum

What a checksum is for

A checksum is a short fingerprint of a file. Feed the same bytes through the same algorithm and you always get the same digest; change a single byte anywhere in the file and the digest changes completely. That property makes it useful for one specific question: did this file arrive exactly as it was published.

Publishers list a checksum next to a download so you can answer that question yourself. Downloads get truncated by dropped connections, corrupted by failing storage, cached in a stale state by a proxy, or served from a mirror that was tampered with. A checksum catches all of those. It catches them cheaply, and it catches them before you run the file rather than after.

The three-step check

Find the checksum the publisher lists. Compute the checksum of your copy. Compare the two strings. If they match, the file is intact.

The comparison is exact. Digests are long hexadecimal strings and the eye is bad at them, so compare by pasting rather than by reading. If you are checking by sight, checking the first six and last six characters catches accidental corruption reliably, though a determined attacker would not be defeated by it.

Where the checksum has to come from

This is the part that gets skipped, and it is the part that matters. A checksum is only meaningful if it came from somewhere the attacker could not also change.

If the download page and the checksum both live on the same server, anyone who replaced the file could replace the checksum next to it, and the two will match perfectly. The check will pass and it will have proved nothing. Read the checksum from the publisher’s own site, their release notes, their signed announcement, or their repository, and download the file from wherever you are getting it. The point is that the two come from different places.

For the same reason, be wary of a checksum sent to you alongside the file. A checksum in the same email as the attachment is decoration.

What it does not prove

A matching checksum proves the bytes are unchanged since the digest was made. It does not prove the file is safe, that the publisher is honest, or that the software does what it claims. A malicious installer published with a correct checksum will verify perfectly.

That distinction matters because checksum verification is often described as a security step when it is really an integrity step. Integrity means the file did not change on the way to you. Trust in what the file does has to come from somewhere else: the publisher’s reputation, a code signature, or a review of the source.

Doing it without handing over the file

Every desktop operating system can hash a file locally. On Windows, Get-FileHash in PowerShell. On macOS and Linux, shasum -a 256 or sha256sum. Nothing is transmitted, and for a large installer this is much faster than any upload.

Browsers can do it too, which is what the hash generator uses. The file is read through the browser’s file API and hashed in the page, so a multi-gigabyte download is verified without sending it anywhere. This is worth insisting on: a site that asks you to upload a file in order to confirm it has not been tampered with has inverted the entire purpose of the exercise, and has taken possession of your file to do it.

Choosing the algorithm

Use whatever the publisher used. SHA-256 is the common default and is what to prefer when you have a choice. SHA-384 and SHA-512 are longer members of the same family and are equally fine.

SHA-1 needs a caveat. In 2017 researchers at CWI Amsterdam and Google produced two different PDFs with the same SHA-1 digest, which ended its usefulness for anything security-related. Some older projects still publish SHA-1 checksums, and comparing against one is reasonable for catching corruption, but a SHA-1 match should not be treated as evidence that nobody interfered.

MD5 is weaker still and should be treated the same way: fine for spotting a truncated download, worthless against a deliberate one.

When the checksums do not match

Download the file again first. A mismatch is far more often a broken transfer than an attack, especially on a large file or an unreliable connection.

If a second download produces the same mismatching digest, stop and check that you are comparing like with like: the right algorithm, the right file, and the checksum for the exact version and platform you downloaded. Publishers commonly list separate checksums per architecture, and comparing against the wrong row produces a confident, meaningless failure.

If everything lines up and the digest still differs, do not run the file. Report it to the publisher, who will want to know whether one of their mirrors is serving something they did not build.