How to Verify a File’s Checksum (SHA-256) and Why It Matters

You download a Linux ISO, a database installer, or a release binary, and the download page lists a long string of hex labelled “SHA-256.” Most people ignore it. It’s actually a thirty-second check that tells you whether the file arrived intact — and, in the right circumstances, whether it’s the genuine article. Here’s what it is, how to verify it on any operating system, and the one limitation worth understanding before you trust it blindly.

What a checksum is

A checksum is the output of a hash function run over the file’s bytes. A hash is a one-way fingerprint: it turns any input into a fixed-length string (SHA-256 produces 64 hex characters), and crucially, changing even a single byte of the input produces a completely different output. There’s no pattern between a small change and a small difference — flip one bit and roughly half the hash characters change.

That property is what makes hashes useful for integrity: if your copy of a file produces the same SHA-256 as the original, the two files are identical, period. (Hashing is one of three operations developers constantly mix up — see encoding vs hashing vs encryption for where each fits.)

How to verify a SHA-256 hash

Compute the file’s hash, then compare it to the published value. Pick whichever matches your setup:

• macOS / Linux: shasum -a 256 filename (or sha256sum filename on most Linux distros)
• Windows (PowerShell): Get-FileHash filename -Algorithm SHA256
• In the browser: drop the file into the File Hash Verifier, which computes the hash locally and compares it for you — handy when you’re not at a terminal, and it never uploads the file.

Then compare the result to the publisher’s value. They must match exactly; a single different character means the file is not the same. If you need to generate hashes of text or strings rather than files, the Hash Generator covers SHA-256, SHA-512, and more.

What a checksum catches — and what it doesn’t

This is where most explanations stop, but it’s the important part.

A matching checksum reliably catches corruption. Interrupted downloads, truncated transfers, a flaky disk, a bad mirror — any accidental change to the bytes makes the hash differ, so a match means the file is complete and unaltered.

Whether it catches tampering depends on where the hash came from. If an attacker can replace the file you download, and the reference hash is published on the same page delivered over the same channel, they can simply replace the hash too — and your “verification” passes against the attacker’s value. In that case the checksum only protects against accidents, not adversaries.

To protect against tampering, the reference hash has to come from a source you trust independently of the file: a different server, a hash you saw earlier, or — best — a cryptographic signature.

When you need a signature instead

A plain hash has no notion of who produced it; anyone can compute one. A digital signature fixes that: the publisher signs the checksum with their private key, and you verify it with their public key (commonly via GPG). A valid signature proves both that the file is intact and that the hash genuinely came from the key holder — closing the “attacker swapped the hash too” gap.

So the hierarchy is: a checksum from the same page guards against corruption; a checksum from a trusted, separate source adds some tamper resistance; a signed checksum gives you real authenticity. (Why a fast hash like SHA-256 is right here but wrong for passwords is its own topic — see bcrypt vs SHA-256.)

The takeaway

Verifying a SHA-256 checksum is a quick, worthwhile habit for anything important you download: compute the hash with your OS’s built-in command or a local verifier, and compare it exactly to the published value. Just be clear-eyed about what a match proves — guaranteed integrity against corruption, and tamper resistance only as strong as the trust in where that reference hash came from. When authenticity truly matters, look for a signature, not just a hash.