How to Verify a File's Checksum (Windows, Mac & Linux)

Why bother verifying a download

Two things can go wrong between a publisher's server and your disk. The file can be corrupted in transit — a dropped connection, a flaky mirror, or a buggy proxy leaves you with a truncated or garbled copy that may install but behave strangely. Or the file can be tampered with — swapped on a compromised mirror or by a network attacker for a version carrying malware. Verifying a checksum catches the first case every time and the second case in many of them.

This is why careful publishers post a checksum (and, ideally, a cryptographic signature) right next to the download link or in a small SHA256SUMS file. The checksum is their promise: "the genuine file produces exactly this fingerprint." Your job is to confirm your copy produces the same one.

The concept: a fingerprint for bytes

A checksum is the output of a hash function such as SHA-256 or MD5 run over the file's raw bytes. It collapses a file of any size into a short, fixed-length string — 64 hexadecimal characters for SHA-256. The function is deterministic, so the same input always yields the same output, yet it is extremely sensitive: flipping a single bit anywhere in the file produces a completely different, unpredictable hash. That avalanche effect is what makes the comparison meaningful. You don't need to inspect a gigabyte of data; you just compute its fingerprint locally and check it against the published one.

The command for your OS

Open a terminal in the folder containing the download (replace file.iso with your filename) and run the row for your system. SHA-256 is the modern default; MD5 commands are included for the cases where a publisher only posted an MD5.

Every one of these prints a hex string. On Windows the Get-FileHash output is an object with a Hash column; certutil prints the hash on its own line between two status messages. On macOS and Linux the hash comes first, followed by the filename.

How to compare safely

The comparison itself is where people slip up. A few rules:

It's case-insensitive. Hex is hex — A3FF and a3ff are the same value. Different tools print different cases, so don't be alarmed by a mismatch in capitalization alone.

Don't eyeball the first few characters. A tampered file can be crafted to share a leading prefix with the real one. Compare the entire string. The reliable way is to let the computer do it: paste the published value and let a tool report a single yes/no.

On Linux and macOS you can verify in one step without reading hashes at all. Put the expected value and filename into the standard format (note the two spaces between them) and pipe it to the checker:

What a mismatch means

If the values differ, the file you have is not the file the publisher hashed. The overwhelmingly common cause is a corrupted or incomplete download, so the first move is simple: delete it and download again, preferably from the official source rather than a third-party mirror. Also double-check that you grabbed the checksum for the exact same version and architecture — comparing a 64-bit ISO against a 32-bit checksum will always fail.

If a clean re-download from the official source still fails to match, treat it as a red flag. A persistent mismatch can mean a bad or hijacked mirror, or that the file has been tampered with. Don't run it.

Integrity is not authenticity

One important limitation: a matching checksum proves integrity — your copy is byte-for-byte identical to the one whose hash was published. It does not, by itself, prove authenticity. If an attacker can replace the download on a server, they can usually replace the checksum posted alongside it too, and both will agree. The fix is a signed checksum: publishers sign their SHA256SUMS file with a GPG key, and you verify that signature against their known public key. The checksum confirms the bytes; the signature confirms who stands behind them.

The no-terminal alternative

If you'd rather not touch a command line, you can hash a file right in your browser with our checksum tool — drag a file in and it computes SHA-256, SHA-1 and MD5 locally. Nothing is uploaded; the file never leaves your device. For quick text or string hashing there's also the MD5 generator and the multi-algorithm hash generator. Whichever route you take, the workflow is the same: compute, then compare the whole string.

Frequently asked questions

What is a file checksum?

A checksum is the output of a hash function (such as SHA-256 or MD5) run over a file's bytes. It is a short fixed-length string that acts as a fingerprint: the same file always produces the same checksum, and changing even one byte produces a completely different one. Publishers post the expected checksum so you can confirm your copy matches theirs.

Which algorithm should I use, SHA-256 or MD5?

Use SHA-256 whenever the publisher offers it. MD5 and SHA-1 are still useful for catching accidental corruption, but they are cryptographically broken and can be deliberately forged, so they should not be relied on to detect tampering. Always match whichever algorithm the published value was generated with.

Does a matching checksum mean the file is safe?

A matching checksum proves integrity, that your file is byte-for-byte identical to the one whose checksum was published. It does not prove authenticity on its own, because an attacker who replaced the download could also replace the posted checksum. For real authenticity you need a signed checksum (for example a GPG signature) and the publisher's trusted public key.

What should I do if the checksum does not match?

First re-download the file, since most mismatches are caused by an interrupted or corrupted transfer. Make sure you compared against the checksum for the exact same version and architecture. If it still does not match after a clean download from the official source, do not run the file; a persistent mismatch can indicate a bad mirror or tampering.

This guide is general technical information. Always obtain checksums and downloads from the publisher's official source.