A checksum published beside a download lets you confirm that the bytes you received are the bytes the publisher intended. Compute the digest of your copy, compare it with the published value, and a match means the file is intact.
The mechanics take one command on any platform. What deserves more attention is what a match actually proves, because a checksum verifies integrity and only sometimes says anything about authenticity.
Verifying on Linux
Use sha256sum file.iso as a SHA256 checksum generator, or md5sum as an MD5 hash checker for the older algorithm. Compare the output against the published value, or automate it by piping the expected digest and filename into sha256sum -c, which reports a plain OK or FAILED.
When a project distributes a SHA256SUMS file listing many releases, run sha256sum -c SHA256SUMS --ignore-missing in the download directory. It checks every file present and skips the entries you did not download, which avoids a wall of failures for files you never wanted.
Verifying on macOS
macOS ships shasum, which needs an explicit algorithm: shasum -a 256 file.dmg. There is also a bare md5 command, whose output format differs from the Linux tool by printing the filename first.
Those formatting differences matter only if a script parses the output. For manual verification, compare the hexadecimal string itself. If you have Homebrew installed, the GNU coreutils package provides gsha256sum with Linux-compatible behaviour, which is convenient for scripts meant to run on both systems.
Verifying on Windows
PowerShell provides Get-FileHash file.exe -Algorithm SHA256, which returns an object containing the digest in uppercase. The classic alternative is certutil -hashfile file.exe SHA256, available on every Windows installation without PowerShell.
Uppercase output is a frequent source of confusion when the published value is lowercase. Hexadecimal is case-insensitive, so the two are identical; normalise both sides before comparing, and never conclude that a file is corrupt because the letter case differs.
Comparing digests without misreading them
A SHA-256 digest is sixty-four characters, and human eyes are unreliable at comparing long hexadecimal strings. Checking the first and last few characters is a habit worth breaking, because it is exactly the shortcut a manipulated value would be designed to survive.
Compare programmatically, or paste both values into a tool that reports a definitive match. When verification fails, the overwhelmingly likely cause is an incomplete or resumed download rather than tampering. Download again before drawing conclusions, and confirm that you are comparing against the checksum for the right version and architecture.
What a matching checksum proves
A match proves the file is byte-identical to the one whose digest was published. That reliably catches truncated downloads, disk errors, and corruption in transit, which is what checksums were introduced to do.
It does not prove who created the file. If an attacker can modify the download, they can usually modify the checksum published on the same page, and both will agree. Integrity verification is only as trustworthy as the channel carrying the expected value.
Signatures close the gap
This is why serious projects publish a signature alongside the checksum file, typically GPG. The signature is verified with the project's public key, obtained independently and ideally confirmed through a separate channel. Verify the signature on the checksum file, then verify files against that checksum list.
That chain gives a property a bare digest cannot: assurance that a specific key holder vouched for the content. Downloading over HTTPS from the official domain provides meaningful protection too, but it authenticates the server rather than the artefact, and it says nothing if the build itself was compromised.
Choosing the algorithm and reading the file
Prefer SHA-256 when a project publishes several digests. MD5 and SHA-1 still detect accidental corruption perfectly well, but both are vulnerable to deliberately constructed collisions, so they should not be relied on where an adversary might have influenced the file.
A checksum file is plain text: each line holds a digest, whitespace, and a filename, sometimes with an asterisk marking binary mode. Keep the file next to the downloads and let the tool do the matching. Manual comparison is where mistakes enter, and the whole point of verification is to remove the chance of a mistake.
Verifying files you did not download
The same technique confirms that a file survived a copy, a backup, or a transfer between machines. Compute the digest at the source, compute it again at the destination, and compare. This catches the silent failures that file size and modification time miss entirely, such as a truncated network copy or a failing disk sector.
For directory trees, generate a checksum file once and re-verify it later. Storing that list alongside an archive turns a future restore into a checkable operation rather than an act of faith, and it identifies precisely which files degraded rather than merely reporting that something is wrong.
Automating verification in a pipeline
Build and deployment scripts should verify every artefact they fetch, and should fail loudly when a digest does not match. Pin the expected value in the script or in a lockfile rather than reading it from the same response that delivered the file, since a compromised source would supply both.
Check the exit status rather than parsing output text, because the format differs across the platform tools described above. Both sha256sum -c and Get-FileHash integrate cleanly this way, and a non-zero status stops a pipeline before a corrupted artefact reaches production.
References: NIST FIPS 180-4 specifies the SHA family, and the OWASP Password Storage Cheat Sheet covers algorithm choice for credentials.