How to verify a download with a checksum

Here is the whole job in one line: run a command that computes your file’s hash, then compare that hash to the one the project published next to the download. If the two strings match, the file arrived complete and unaltered. If they differ by even one character, don’t trust it.

TL;DR: A checksum is a fixed-length hash of a file, usually SHA-256. Compute the hash of your download with a built-in command, compare it character for character with the value the project published, and a match means the file is intact. A checksum catches corruption and swaps against the posted hash, but it can’t tell you the posted hash itself is genuine. That takes a signature.

The commands, so you can start now

Pick your platform, drop in your filename, and read the result.

macOS, in Terminal:

shasum -a 256 yourfile.iso

Linux, in a terminal:

sha256sum yourfile.iso

Windows, in Command Prompt:

certutil -hashfile yourfile.iso SHA256

Each one prints a 64-character string. That’s your file’s SHA-256 hash. Now find the hash the project published, usually on the download page and labelled with the algorithm, and compare the two.

The strings are long, so don’t glance at the first few characters and call it a match. Copy the published value, copy your computed value, and check them character for character, or paste both into something that highlights a difference. A single mismatched character means the files are not the same.

If you’d rather not touch a terminal, you can drop the file into a file hash and checksum tool that runs entirely in your browser, so the file is never uploaded anywhere, and read the SHA-256 value off the screen.

What a checksum actually is

A checksum is a short fingerprint of a file. You feed the file’s bytes through a hash function, and out comes a fixed-length string that stands in for the whole file. A SHA-256 hash is always 256 bits, written as 64 hexadecimal characters, whether the input is a one-line text file or a multi-gigabyte disk image. The size of the file has nothing to do with the size of the fingerprint.

The fingerprint is for comparison, not storage. The hash does not contain the file, and it’s far too small to. What it gives you is a value two people can compute independently and check against each other. The project hashes the file once and publishes the result. You hash your copy and compare. Same input, same hash function, same output, every time. That repeatability is the entire mechanism.

Why one changed bit breaks the whole hash

This is the part worth understanding, because it’s why the check works at all. Hash functions are built so a tiny change to the input scrambles the entire output. Flip a single bit in a multi-gigabyte file and the SHA-256 result is completely different, with no resemblance to the original. This property is called the avalanche effect.

So there is no “close enough.” The two hashes are either identical or they’re not. You never have to judge how different they are or how much corruption you’ll tolerate. A match means every byte lines up. A mismatch, even of one character, means something differs, and the hash alone won’t tell you whether it was a dropped packet or a deliberately altered file. Either way the answer is the same: don’t trust this copy, download it again.

It also means you can’t fake a match by tweaking the file a little. There’s no gentle nudge that lands back on the same hash.

What a matching hash does and does not prove

Here’s the boundary most write-ups skip, and it matters.

A checksum proves exactly one thing: your file is identical to the file that produced this hash. That’s genuinely useful. Files break in transit more often than people assume. A connection drops mid-download, a mirror serves a stale copy, a proxy mangles a few bytes, or a storage server hands back a corrupted chunk. Hash your copy, compare to the published value, and a match tells you the bytes you have are the bytes they published.

It also catches a swap, as long as the attacker changed only the file. If someone replaces the installer on a compromised mirror but can’t touch the hash the project posted on its own trusted site, the mismatch gives them away.

Now the honest limit. A checksum only proves your file matches the hash you compared it against. It says nothing about whether that hash is the real one. If an attacker controls the page and replaces both the file and the posted hash, your download will match their hash perfectly and prove nothing. You verified the file against a value the attacker chose.

That is why a checksum on its own is integrity, not trust. To close the gap you need a cryptographic signature, usually GPG. A signature ties the hash to a private key that only the project holds, and you verify it against their public key, which you got separately and can check. The checksum proves the file matches a hash. The signature proves the project is the one who vouched for that hash. For a high-stakes download, look for the signature, not just the string next to the link.

Corruption versus tampering, and which hash to use

Which hash function you use depends on the threat.

For catching accidental corruption, almost any hash works, including the older MD5 and SHA-1. Corruption is random, so even a broken function will produce a different value for a mangled file. If a project only offers an MD5 checksum and you just want to confirm the download didn’t get garbled, that MD5 is adequate.

Tampering is a different threat, because now someone is deliberately trying to fool you. MD5 and SHA-1 are broken for security: researchers have shown attackers can construct two different files that share the same hash, which is called a collision. So a match on a weak function no longer guarantees you have the file you wanted. When authenticity matters, use SHA-256, which has no practical collisions and is the current standard. The commands above already ask for SHA-256, which is why they’re the ones to reach for.

What a checksum is not

A checksum is not encryption and it hides nothing. Hashing is one-way. You can’t run the process backward to recover the file, and the hash reveals nothing about the contents. It’s a fingerprint, not a locked box. Anyone can compute the hash of a file they already have, which is the whole point, because that’s how you both arrive at the same value.

So a checksum answers one question: is this file identical to the one with this fingerprint? It doesn’t keep the file private, protect it, or encrypt it. If you need secrecy, that’s a job for encryption with a key, a separate tool for a separate problem. Used for what it’s meant for, and paired with a signature when the stakes are high, a checksum is a fast, reliable way to confirm a download arrived whole. That’s worth the minute it takes.