Download an operating system image, a database installer or a signed PDF and you will often find a long hexadecimal string published next to the link. That is a checksum, and comparing it against your copy is a fast, worthwhile habit.
What you are checking
The publisher computed a cryptographic hash, usually SHA-256, of the exact file they intended to distribute. You compute the same hash of the file you received. If the strings match character for character, your copy is byte-identical to theirs.
Because good hash functions have an avalanche property, a single flipped bit anywhere in a 4 GB file produces a completely different hash. There is no "close enough".
Doing it
On Linux:
sha256sum ubuntu-24.04.iso
On macOS:
shasum -a 256 installer.dmg
On Windows (PowerShell):
Get-FileHash installer.exe -Algorithm SHA256
Then compare to the published value. Compare the whole string, checking the first and last six characters is a habit worth avoiding, because a targeted attack can afford to search for a partial match.
What it catches
- Incomplete or corrupted downloads. Common on flaky connections, and the most frequent real cause of a mismatch.
- A compromised mirror. Large projects distribute through many mirrors; a mirror serving a modified installer is a known attack pattern with real historical examples.
- Bit rot on old storage.
- The wrong file entirely, a different version than you thought.
What it does not catch
Here is the important limitation. If the checksum and the file come from the same place, an attacker who controls that place controls both. Someone who compromises a project's website can replace the installer and update the published hash. Your verification then passes perfectly against a malicious file.
Checksums protect against a compromised distribution channel, not a compromised source.
Stronger options, in increasing order:
- Fetch the checksum over HTTPS from the canonical domain, not from the mirror serving the file. This is the minimum that makes the exercise meaningful.
- Use a GPG signature where the project publishes one. A signature proves the file was signed by a specific private key, which an attacker who defaces a website does not have. This requires having the project's public key from a trusted source, which is the part people skip.
- Check the hash against a second independent source, such as the project's GitHub releases page versus their website.
MD5 checksums are still everywhere
Plenty of projects still publish MD5 sums. MD5 collisions are practical, so an attacker can in principle construct a malicious file matching a published MD5.
An MD5 sum is still useful for detecting accidental corruption. It is not useful against a deliberate attacker. If a project offers both, use the SHA-256.
Where else this matters
- Backups. Hash a file when you archive it, hash it again on restore. This is how you find out that a backup went bad before you need it.
- Deduplication. Files with identical hashes are identical files. This is how deduplicating storage systems work.
- Evidence and record-keeping. Recording a hash at a point in time proves a document has not been altered since, provided the hash was recorded somewhere the document's holder cannot change.
- Confirming a transfer. Hash before sending and after receiving to prove the transfer was clean.
Checking a file without handing it over
Hashing requires reading every byte, so an online checksum tool that uploads your file has just received a complete copy of whatever you were verifying, often a large installer, sometimes a private archive.
Browsers implement SHA-256 natively through the Web Crypto API, so a checksum can be computed without sending the file anywhere. The file checksum tool reads the file from disk and hashes it in the tab; paste the published value into its compare box and it tells you whether they match.