Checksums: how to verify a downloaded file is genuine

Toolkit Guides · Updated July 2026 · 6 min read

Next to the download button for an operating system image, an installer or a firmware file, there's often a line like SHA-256: 9f86d081884c7d65…. Most people scroll straight past it. That string is a fingerprint of the exact file the publisher released, checking your copy against it takes about thirty seconds in a browser, and knowing what a match proves — and what it doesn't — is most of what there is to know about download security.

A fingerprint for files

A checksum (more precisely, a cryptographic hash) is the output of a function that reads every byte of a file and boils it down to a short, fixed-size fingerprint. SHA-256 output is always 256 bits — written as 64 hexadecimal characters — whether it digested a one-line text file or an 8 GB DVD image. The same input produces the same fingerprint every time, on any machine; that's what makes it a fingerprint rather than a random tag.

The property that makes hashes useful for verification is how violently the output reacts to input changes. Hash the word hello with SHA-256 and it begins 2cf24dba5fb0…; capitalize one letter to Hello and it begins 185f8db32271… — not one character of the two fingerprints lines up. Flip a single bit anywhere in a multi-gigabyte file and the entire fingerprint scrambles. There's no such thing as "close": two files either match exactly or produce unrelated hashes. You can watch this live by typing in the hash generator and changing one letter.

Hashes are also one-way — the fingerprint reveals nothing about the file's contents — and, for modern algorithms, it is computationally infeasible to construct a different file that produces the same fingerprint. Those two properties together are what let a 64-character string stand in for gigabytes.

Why publishers list them

Downloads go wrong in two very different ways, and a checksum catches both.

Accident. Transfers get truncated by flaky connections, corrupted by failing disks or bad RAM, or mangled by proxies. A half-broken video mostly still plays; a half-broken OS image can fail hours into an installation with an error that says nothing about the real cause. Comparing checksums before you start turns "mysterious install failure" into "re-download the file."

Attack. Big projects rarely serve every download themselves — files are pushed out through mirrors and CDNs the project doesn't fully control. Publishing the fingerprint on the project's own page means you can fetch the bits from any mirror, hash what arrived, and confirm it's byte-for-byte the file the developers released, no matter whose server it traveled through. Package managers like apt and Homebrew do exactly this automatically for every package; a file you download with a browser gets checked only if you check it.

How to verify in thirty seconds

Copy the published hash from the download page. Its length tells you the algorithm: 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256, 128 is SHA-512.
Open the checksum tool and drop in the downloaded file. The file is read and hashed locally on your machine — nothing is uploaded, which matters when the thing you're verifying is a 6 GB image. (Here's how in-browser processing works if that sounds implausible.)
Paste the published hash into the compare box. The tool computes MD5, SHA-1, SHA-256 and SHA-512 side by side and highlights whichever one matches — you don't even need to have identified the algorithm correctly.
Read the verdict. A match means your copy is byte-for-byte identical to what the publisher listed. No match means stop — see below.

Try it: the file checksum tool hashes any file entirely in your browser and checks it against a pasted fingerprint in one step. Feed it any file on your disk to see all four hashes appear.

If you prefer a terminal, the one-liners are shasum -a 256 file.iso on macOS and Linux, and certutil -hashfile file.iso SHA256 on Windows. Same math, fewer clicks to trust.

When the hashes don't match

Don't reach for the antivirus yet — most mismatches are mundane. Check, in order: that you downloaded the same version the hash belongs to (publishers list one hash per release, and "latest" moves); that you hashed the right file; and that the download actually finished — a truncated file is the classic cause. Then re-download once, ideally from the project's primary site rather than a mirror, and compare again.

If a complete, correct-version download from the official source still doesn't match the official fingerprint, treat the file as hostile: don't run it, don't "just this once" it, and let the project know. That outcome is rare, but it is the exact scenario checksums exist to catch — and the cost of respecting a mismatch is one skipped installer.

What a match proves — and what it doesn't

A matching checksum proves precisely one thing: your file is identical to the file whose fingerprint the publisher listed. No corruption in transit, no mirror swapping in a doctored build. That's genuinely valuable — and it's all it proves.

It does not prove the publisher is trustworthy, or that the file is free of malware; a perfectly verified download of a malicious program is still malicious. And there's a subtler gap: if the download page itself is compromised, the attacker can replace the file and the listed hash in the same edit, and your verification will pass while verifying the attacker's build. A checksum displayed on the same server as the file defends against corruption and rogue mirrors, not against the source itself being taken over.

Closing that last gap is what digital signatures are for. A signature (GPG, minisign, OS code-signing) is created with a private key the project holds — ideally off the web server entirely — and your computer verifies it with the project's public key. A web-server intruder can swap a text file listing hashes; they can't forge a signature without stealing that key. The practical hierarchy: a checksum proves integrity (these are the bytes), a signature proves origin (these bytes came from the key holder). Serious projects publish both, and for everyday downloads the checksum is the 80% you can get for thirty seconds of effort.

MD5, SHA-1, SHA-256: which to trust

Algorithm	Fingerprint length	Collision-resistant today?	Reasonable use
MD5	32 hex characters	No — practical collisions since 2004	Corruption checks only
SHA-1	40 hex characters	No — public collision demonstrated in 2017	Legacy compatibility
SHA-256	64 hex characters	Yes, no known collisions	The default for verifying downloads
SHA-512	128 hex characters	Yes, no known collisions	Equally sound; sometimes faster on 64-bit hardware

"Broken" here means researchers can deliberately construct two different files with the same fingerprint. That doesn't happen by accident — the odds against a chance MD5 collision are still astronomical — so an MD5 listed next to a download remains a perfectly good detector of truncation and bit rot. What it can no longer do is stand up to an adversary who prepares both files. If a project you rely on lists only MD5 for security purposes, read that as a sign of unmaintained infrastructure; if you're publishing files yourself, list SHA-256.

When it's worth the thirty seconds

Nobody verifies every download, and you don't need to. The habit pays for itself on a short list: operating system images before you install or flash them, installers that will run with administrator rights, financial and tax software, firmware for routers and devices, and anything fetched from a mirror, torrent or other secondhand source rather than straight from the publisher. The common thread is blast radius — verify the files that could take the whole machine down with them, and let the wallpapers through unexamined.