Skip to content

How to check a file's checksum, and what it actually proves

Published · 4 min read · Last reviewed

You download an installer, and the page you got it from lists a long string of hex next to it labelled SHA-256. Most people ignore it. It takes about thirty seconds to check, and it is worth understanding both what that check buys you and what it does not — because the common assumption is wrong in a way that matters.

What a checksum is

A cryptographic hash function takes any amount of data and produces a fixed-length fingerprint of it. SHA-256 always produces 64 hex characters, whether you feed it a three-byte file or a three-gigabyte one.

Two properties make it useful here. The same input always produces the same output, so two people hashing the same file anywhere in the world get the same string. And changing the input at all — one byte, one bit — produces a completely different output, not a similar one. There is no “close”: a file that is 99.99% intact hashes to something with no visible relationship to the original.

So comparing a hash you computed against a hash the publisher printed answers one question precisely: is the file I have byte-for-byte the file they hashed?

How to compute one

You do not need to install anything on any of the three major platforms.

Windows, in PowerShell:

Get-FileHash -Algorithm SHA256 .\installer.exe

macOS and Linux, in a terminal:

shasum -a 256 installer.dmg

In a browser, without a terminal at all: open Hash Generator and add the file. It computes SHA-256, SHA-1, and MD5 using the browser’s own crypto.subtle implementation — the same primitives that secure HTTPS in that browser, not a reimplementation. Nothing is uploaded, which for this particular task is not a nicety but the entire point: sending a file somewhere to check whether it has been tampered with adds exactly the risk you were trying to rule out.

Comparing them properly

Do not eyeball it. Human beings are extremely good at seeing two 64-character hex strings and concluding they match because the first six and last six characters do — and an attacker who has gone to the trouble of substituting your download has certainly thought of that.

Copy the published hash, paste it, and let the computer compare. In PowerShell:

(Get-FileHash -Algorithm SHA256 .\installer.exe).Hash -eq 'PASTE_THE_PUBLISHED_HASH'

That prints True or False, which is the only answer you want. Case does not matter — hex is hex — but nothing else about the string does either, so paste it whole.

What it proves, and what it does not

Here is the part that is usually skipped.

A matching checksum proves your copy is identical to the file the publisher hashed. It catches a download that was truncated, a mirror that served a stale or corrupted build, and a file that was modified somewhere between them and you.

It does not prove the file is safe. If the publisher’s own build was compromised, the hash they published is the hash of the compromised file, and it will match perfectly.

More importantly: if an attacker can serve you a modified download, they can very often serve you a modified web page too — including the line that prints the expected hash. A checksum you read from the same server that gave you the file, over the same connection, mostly proves the server is internally consistent with itself.

That is why the checksum is worth the most when it comes from somewhere else: a different domain, a signed release note, a package manager’s manifest, a repository you already trust. And it is why serious projects sign their checksum files with a GPG key rather than just printing them — the signature is what ties the hash to an identity, and the hash is what ties that identity to the bytes.

Which algorithm to use

Use SHA-256 when you have the choice. It is the current default and there is no practical attack against it.

MD5 and SHA-1 are broken for this purpose. Not “old” — broken. Researchers have produced collisions for both: two different files with the same hash, constructed deliberately. SHA-1’s first public collision landed in 2017, and MD5’s much earlier than that. If a project still publishes only an MD5, it will catch an accidentally corrupted download, and it is not evidence against a deliberate one.

Both are still worth computing sometimes, which is why the tool offers them: plenty of older systems, asset pipelines, and internal registries still key on MD5, and you occasionally need to match what one of them expects. Knowing why it is there is different from trusting it for security.

The everyday version

For most people the useful habit is small: when a download page bothers to publish a SHA-256, spend the thirty seconds. It costs almost nothing and it catches the boring failure — the mirror that served you half a file — far more often than it catches an attack.

And if you are checking whether two files you already have are the same, a hash is the fastest honest answer there is. Same hash, same bytes. Different hash, and no amount of looking at them will tell you where they diverged, only that they do.


Related: Hash Generator computes SHA-256, SHA-1, and MD5 for any file in your browser. Base64 Encoder and Decoder handles the other common “what format is this in” question — and, unlike a hash, is fully reversible by design.