How to verify a file checksum

You download an installer, a disk image, or a release archive, and the project's site lists a long string of hexadecimal next to it labelled SHA-256. Most people scroll past it. It takes about thirty seconds to check, and it is the difference between running software you have verified and software you have merely received.

What a checksum actually is

A checksum is the output of a cryptographic hash function — a fixed-length fingerprint computed from every byte of a file. Two properties make it useful:

• Deterministic. The same file always produces the same hash, on any machine, in any operating system, forever.
• Avalanche effect. Change a single bit anywhere in the file and the hash changes completely — not slightly, but into an entirely unrelated value.

So if the hash of your download matches the hash the publisher printed, your copy is byte-for-byte identical to theirs. If it differs by even one character, something changed.

How to check one

Every operating system ships a command-line tool, and there is a browser option that avoids the terminal entirely.

Or use the hash generator, choose Hash a file instead, and pick the download. It computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 at once, which saves guessing at which algorithm the project published.

This is a case where uploading would be genuinely absurd: you would be sending an entire ISO to a stranger's server, and waiting on the upload, to perform arithmetic your own CPU does in seconds. Hashing there runs in your browser — SHA digests via the built-in WebCrypto API — so the file never leaves your machine and there is no size limit beyond your available memory.

Compare the whole string

Checking the first and last few characters is not enough. Compare the full value, or paste both strings into the diff checker and let it tell you. Case does not matter — A3F and a3f are the same hexadecimal — so if your tool prints uppercase and the site shows lowercase, that alone is not a mismatch.

What a match proves, and what it doesn't

This is where most explanations stop, and it is the part worth understanding properly.

A matching checksum proves the file was not corrupted in transit — an interrupted download, a bad disk, a flaky mirror — and that it was not tampered with by anyone who could modify the file but not the page publishing the hash. That covers a compromised download mirror or CDN, which is a realistic and common threat.

A matching checksum does not prove the file is trustworthy. If an attacker controls the server hosting both the file and the checksum, they will simply publish the hash of their modified file, and the two will agree perfectly. Verification against a value from the same compromised source proves only internal consistency.

That gap is what cryptographic signatures exist to close. A GPG-signed release can be verified against a public key you obtained independently, so a compromised server cannot forge it. When a project offers signatures alongside checksums, the signature is the stronger check. Checksums remain worth doing because they are quick, and because they catch the most common failure — corruption — that signatures are overkill for.

Which algorithm should you trust?

• SHA-256 — the current standard, and what you should prefer whenever a project offers it.
• SHA-512 — a wider digest from the same family. On 64-bit hardware it is often faster than SHA-256 despite the longer output.
• SHA-1 — broken for collision resistance since the 2017 SHAttered attack. Fine as a corruption check, not as protection against a deliberate attacker.
• MD5 — thoroughly broken; collisions can be produced in seconds. Treat an MD5-only checksum as a corruption check and nothing more.

"Broken" here has a specific meaning: an attacker can construct two different files with the same hash. It does not mean MD5 fails to notice a truncated download. If MD5 is all a project publishes, checking it is still better than checking nothing.

Other things checksums are good for

Because identical files always produce identical hashes regardless of filename, hashing answers questions that are otherwise tedious:

• Are these two files actually the same? Two copies with different names, dates, or locations — hash both and compare.
• Did this file change? Record the hash now, recompute later.
• Did the transfer work? Hash before and after copying to a drive or across a network.

One thing hashes are not for: storing passwords. SHA and MD5 are built to be fast, and speed is exactly what an attacker with a leaked database wants. Password storage needs a deliberately slow, salted algorithm — bcrypt, scrypt, or Argon2. If you need strong passwords rather than fingerprints, see how to generate a strong password.