How to verify a downloaded file with a checksum (SHA-256, MD5)

Software publishers often list a "checksum" or "hash" next to their downloads — a long string like e3b0c442…b855. Computing the same hash on the file you received and comparing the two tells you whether you have exactly the bytes the publisher hashed. It tells you nothing about whether the publisher, or the page you read the checksum on, is trustworthy.

The quickest route here: drop your file into the File checksum calculator. It computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 locally — the file is never uploaded — and if you paste the published value into Expected checksum it compares against every algorithm and reports Match or No match.

What a checksum actually is

A cryptographic hash function reads a file of any length and produces a fixed-length fingerprint. The same input always produces the same output, and changing anything at all changes the output completely.

The change really is complete, not proportional. Hashing the text hello with SHA-256 gives 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824; changing the last letter to hellp gives fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7. Those two values differ in 131 of their 256 bits — about half, which is what you would expect from an unrelated random number. There is no such thing as a "close" match: a checksum either matches or it does not.

What it proves, and what it does not

Question	Does a matching checksum answer it?
Was the download corrupted in transit or on disk?	Yes
Is this the same file the publisher hashed?	Yes
Did the file come from the publisher at all?	No
Is the software safe to run?	No

A checksum gives you integrity, not authenticity. If an attacker can replace the download, they can usually replace the checksum on the same page, and both will agree. The checksum is only as trustworthy as the channel it came from: prefer the publisher's own HTTPS site, and better still a checksum file signed with the project's GPG key, which you then verify against a key you already trust.

A practical middle ground: read the checksum from the official site over HTTPS, and the file from whatever mirror is fastest. That combination detects a compromised or stale mirror, which is the common case.

The commands, per operating system

System	Command
Windows (Command Prompt)	certutil -hashfile file SHA256
Windows (PowerShell)	Get-FileHash -Algorithm SHA256 file
macOS	shasum -a 256 file
Linux	sha256sum file

On Linux and macOS you can also verify a whole list at once. Projects that publish a SHA256SUMS file expect this:

sha256sum -c SHA256SUMS

which prints filename: OK for each file it finds and matches. Hex digits have no case of their own, so a digest may be printed in upper or lower case depending on the tool, and some commands insert spaces between byte pairs. None of that changes the value: ignore case and whitespace when comparing, or paste the digest into the tool above, which normalises it for you.

SHA-256, MD5 and the rest

Algorithm	Digest	Hex characters	Use it?
MD5	128 bits	32	Accidental corruption only
SHA-1	160 bits	40	Legacy; avoid for new work
SHA-256	256 bits	64	Yes, the current default
SHA-512	512 bits	128	Yes; often faster on 64-bit CPUs

MD5 and SHA-1 still detect a truncated download or a flipped bit perfectly well. What they no longer resist is a deliberate attack: public practical collisions for MD5 date from 2004, and a full SHA-1 collision was demonstrated in 2017. An attacker able to craft two files with the same digest can get one approved and ship the other. SHA-256 has 2^256 possible outputs — roughly 1.16 × 10^77 — and no such attack is known against it.

If a publisher only offers MD5, use it as a corruption check and look for a signature elsewhere rather than treating the match as proof of origin.

Step by step

1. Find the checksum on the publisher's official site, usually labelled SHA-256. Note which algorithm it is: a 32-character value is MD5, a 64-character one is SHA-256.
2. Drop your downloaded file into the File checksum calculator, or run the command for your system.
3. Compare. Paste the published value into Expected checksum rather than reading 64 characters by eye — or, if you have two hashes in text form, paste both into Text compare, which highlights the differing characters.

Do not compare only the first and last few characters. That is enough to catch a wrong file, but it is exactly the shortcut a substituted file would be designed to survive.

When it does not match

• Re-download, preferably from the official source. Interrupted transfers are the most common cause.
• Check you hashed the right file — an installer inside a .zip has a different hash from the .zip itself.
• Check the algorithm. A SHA-256 value will never match an MD5 digest, and the tool tells you which algorithm did match.
• Watch for a zero-byte file. e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is the SHA-256 of an empty input; seeing it means the download produced nothing at all.
• If it still does not match, do not run the file. Report it to the publisher instead.

Hashing text rather than files

To hash a string — checking a webhook signature, comparing two configuration values, reproducing a digest from documentation — use the Hash generator. Note that digests are not always shown in hexadecimal: npm's integrity field and Subresource Integrity attributes publish them in Base64, as in sha512-…, which the Base64 encoder and the guide Base64 explained can help you read.

One thing hashes like these are not for: storing passwords. SHA-256 is designed to be fast, which is the opposite of what password storage needs — that calls for a deliberately slow, salted function such as bcrypt, scrypt or Argon2. The guide How to create a strong password covers the other side of that problem.

Questions people ask

Is my file uploaded to check it? No. The file is read and hashed inside your browser, up to about 500 MB depending on your device's memory. Larger images are better handled with the command line.

Why does my hash take so long? The whole file has to be read. Time is dominated by disk speed and file size; a multi-gigabyte ISO takes a while whatever tool you use.

Two different files with the same SHA-256 — possible? Mathematically yes, since there are more possible files than digests. No one has ever exhibited such a pair for SHA-256.

Does the file name matter? No. Hashes are computed over the contents only, so renaming a file never changes its checksum.

Next steps

• Verify a download: File checksum calculator
• Hash a piece of text: Hash generator
• Compare two long strings: Text compare