How to verify a download with a checksum

Projects often publish a string of letters and numbers right next to a download link, labelled something like SHA-256 or MD5. Most people scroll past it. That string is a checksum, and it lets you confirm, in under a minute, that the file you received is exactly the file they published. Here is how it works and how to actually use it.

TL;DR: A checksum is a fixed-length fingerprint of a file, produced by a hash function such as SHA-256. To verify a download, compute the hash of your copy and compare it character for character with the one the project published. If they match, the file arrived complete and unaltered. If they differ by even one character, something changed, and you should not trust the file.

What a checksum actually is

A checksum is a short fingerprint of a file. You run the file’s bytes through a hash function, and out comes a fixed-length string that represents the entire 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 does not change the size of the fingerprint.

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

This is why a checksum is sometimes called a digest. It boils a large thing down to a small, comparable summary, while staying perfectly repeatable.

Why projects publish a hash next to a download

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. The published checksum exists so you can catch all of that. Hash your copy, compare it to the published value, and a match tells you the bytes you have are the bytes they sent.

There is a second, more serious reason. A download can be swapped for a malicious version, on a compromised mirror or through an intercepted connection. If an attacker replaces the installer but cannot change the checksum the project published on its own trusted site, the mismatch gives them away. The hash turns “I hope this is the real file” into something you can check.

That second case only holds if the checksum itself is trustworthy, which is where the source of the hash starts to matter. More on that below.

How to verify a download step by step

Verifying is a three-step loop: get the published hash, compute the hash of your file, and compare them. Find the checksum on the project’s official download page, usually labelled with the algorithm. Then compute the same kind of hash over the file you downloaded. Finally compare the two strings. If they are identical, the file is intact.

You can compute the hash with a built-in command. On macOS or Linux, shasum -a 256 yourfile.iso prints the SHA-256 digest. On Windows, certutil -hashfile yourfile.iso SHA256 does the same. If you would 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.

Now compare. The hashes are long, so do not eyeball the middle and assume. Copy the published value, copy your computed value, and check them character for character, or paste both somewhere that highlights a difference. A single mismatched character means the files are not the same.

Why one changed byte breaks the whole hash

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 hash. This is called the avalanche effect, and it is the property that makes checksums useful. There is no “close enough” match. The hashes are either identical or they are not.

That all-or-nothing behaviour is exactly what you want for verification. You never have to judge how different two hashes are or how much corruption is acceptable. A match means every byte lines up. A mismatch, even of one character, means at least something differs, and you cannot tell from the hash alone whether it was a harmless dropped packet or a deliberately altered file. Either way the answer is the same: do not trust this copy, download it again.

It also means you cannot fake a match by tweaking the file a little. There is no gentle nudge that lands on the same hash.

Corruption versus tampering, and which hash to use

For catching accidental corruption, almost any hash function works, including the older MD5 and SHA-1. Corruption is random, so even a broken hash function will almost certainly produce a different value for a mangled file. If a project only offers an MD5 checksum and your goal is to confirm the download did not get garbled, that MD5 is perfectly adequate.

Tampering is a different threat, because now someone is deliberately trying to fool you. MD5 and SHA-1 are considered broken for security, since researchers have shown attackers can construct two different files that share the same hash, a collision. That means a checksum match on a weak function no longer guarantees the file is the one you wanted. For anything where authenticity matters, prefer SHA-256, which has no practical collisions and is the current standard.

There is one more layer. A checksum only proves the file matches the published hash. If an attacker controls the page, they can change both the file and the hash. That is why high-stakes downloads pair the checksum with a cryptographic signature, so you can confirm the hash itself came from the project and not an impostor. The checksum proves integrity. The signature proves who vouched for it.

What a checksum is not

A checksum is not encryption and it does not hide anything. Hashing is one-way: you cannot run the process backward to recover the file, and the hash reveals nothing about the contents. It is a fingerprint, not a locked box. Anyone can compute the hash of a file they already have, which is the entire point, because that is how verification works.

So a checksum answers exactly one question: is this file identical to the one with this fingerprint? It does not keep the file private, it does not protect it, and it does not encrypt it. If you need secrecy, that is a job for encryption with a key, which is a separate tool for a separate problem. Used for what it is meant for, a checksum is a fast, reliable way to confirm a download arrived whole and unchanged, and that is worth the minute it takes.