Verifying a download with a checksum, step by step

A checksum lets you prove a file arrived exactly as its publisher sent it — byte for byte. This walkthrough explains what you are actually comparing, how to do it on any system, and the one situation where a matching checksum still proves nothing.

When a download page publishes a string like 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 next to a file, it is offering you a test: run the same hash function over the file you received, and if your string matches theirs, the bytes you hold are the bytes they published. That string is the file's SHA-256 hash — a 256-bit fingerprint computed from the file's contents and nothing else.

It takes two minutes, it needs no account and no special software, and it catches a real class of problems: truncated downloads, corrupted mirrors, files swapped after publication. This guide does it once, carefully, and then explains the limits honestly.

What is actually being compared

A hash function reads a stream of bytes and produces a fixed-length output. Change one bit anywhere in a gigabyte file and roughly half the output bits flip. The publisher hashed the file on their machine and printed the result; you hash your copy on yours. If both outputs agree, then — because finding two different files with the same SHA-256 is computationally out of reach — your file is their file.

Note what is not involved: the filename, the download date, the website it came from. Rename the file and its hash is unchanged. Zip it and the zip has a different hash, because the bytes changed even though the contents did not. The checksum certifies bytes, not meaning.

The check, step by step

1. Find the published checksum on the download page. Projects usually label it SHA-256, SHA-512 or "checksum". Copy it exactly, and note the algorithm named next to it — comparing your SHA-256 against their MD5 will never match and tells you nothing.
2. Download the file as normal and leave it where it lands. Do not open or run it yet.
3. Hash your copy. On Windows, Get-FileHash filename in PowerShell defaults to SHA-256. On macOS, shasum -a 256 filename. On Linux, sha256sum filename. Or drop the file into a browser-based hash tool — the file is read locally and hashed on your device.
4. Compare the two strings character by character — or paste both into a text field and search one for the other. Case does not matter; hex digits may be printed upper or lower. Length does: SHA-256 is always 64 hex characters, SHA-512 is 128, MD5 is 32.
5. Act on the result. Match: proceed. Mismatch: delete the file and download again, ideally from a different mirror. A persistent mismatch is a red flag worth reporting to the publisher, not working around.

Reading the result honestly: what a match does not prove

A checksum verifies integrity against the publisher's stated fingerprint. It does not verify the publisher. If an attacker compromises the download server and replaces both the file and the checksum beside it, your comparison passes beautifully — you have faithfully verified the attacker's file. Checksums and transport security answer different questions: HTTPS tells you the file came from the server you addressed; a checksum tells you the bytes match a fingerprint. When both the file and its fingerprint travelled over the same connection from the same server, the second check adds protection against corruption and mirror mix-ups, but little against a compromised source.

That is why serious projects separate the channels: fingerprints published on a different domain, in a signed release announcement, or confirmed by a digital signature (such as a PGP-signed checksum file), where the signature — not the hash — is what ties the fingerprint to the publisher's identity. For most everyday downloads, a checksum from the project page plus HTTPS is a sensible, proportionate check. Just know which threats it covers.

When the published checksum is only MD5 or SHA-1

Plenty of older projects still publish MD5 alone. Both MD5 and SHA-1 are broken for collision resistance: researchers can construct two different files with the same digest, which means a malicious file can be crafted to pass an MD5 check. Used purely as an accident detector — did my download corrupt? — MD5 still works fine, because random corruption does not engineer collisions. Used as evidence that a file is the genuine article, it is weak. Where a project offers SHA-256 or SHA-512 alongside, always compare that one.

Mistakes and pitfalls

Comparing hashes from different algorithms

A 64-character SHA-256 will never equal a 32-character MD5 of the same file. The most common cause of a "failed" verification is not a bad file — it is hashing with the wrong function. Check the label on the published value first.

Trusting a checksum pasted next to the download button, from the same compromised page

If the page itself is the thing you doubt, a fingerprint printed on it cannot reassure you. Cross-check the value in a second location — a release note, a repository tag, a signed announcement.

Verifying after installing

The whole point is to check before running. Hash the installer first; an installed program's files may legitimately differ from the download, and by then the check has lost its purpose.

Common questions

My hash almost matches but a few characters differ. Is that close enough?

No. Hash outputs are all-or-nothing: a one-character difference means a different file (or a different algorithm). There is no partial credit, by design — the avalanche effect guarantees near-matches for trivially different inputs.

Can I verify a file without installing anything?

Yes. Every operating system ships a tool — PowerShell's Get-FileHash, macOS's shasum, Linux's sha256sum — and browser-based hash tools can read and hash a file locally without uploading it.

Does a matching checksum mean the software is safe?

It means the software is what the publisher published, assuming the fingerprint itself is genuine. Publishers can ship buggy or even malicious software with perfectly valid checksums. Integrity and trustworthiness are separate judgements.

To wrap up

Checksum verification is a small habit with an unusually good effort-to-value ratio: one command, one comparison, and a whole category of silent corruption and tampering is ruled out. Learn it on a file you do not care about, and it will be muscle memory on the day you do.

Keep the habit proportionate, though. You do not need to verify a song sample from a store you already trust with your card details; you absolutely should verify an operating-system image, a cryptocurrency wallet, a browser installer or anything you are about to run with administrator rights. The pattern is simple to state and worth internalising: the more authority a file will have over your machine and your data, the less acceptable "it downloaded without an error" becomes as the entirety of your diligence.