How to verify a download with a checksum

You have downloaded an ISO or an installer, and the download page shows a long hex string labelled SHA256, or offers a file called SHA256SUMS. The instruction is always the same: check that it matches. Almost nobody explains what matching actually buys you.

Here is the honest version. A checksum proves the file you have is byte-for-byte identical to the file whose hash was published. That is all it proves. Whether that is worth anything depends entirely on where the hash came from.

What the check actually proves

Running a file through SHA-256 produces a fixed-length fingerprint. Change one byte anywhere in the file and the fingerprint changes completely. So if your computed hash matches the published one, you can be confident the file arrived intact.

That covers a real and common problem: downloads genuinely do get corrupted. A connection drops and resumes badly, a disk writes a bad sector, a mirror serves a truncated file. The symptom is an installer that fails halfway through with something unhelpful, and the checksum tells you in two seconds that the file — not the installer — is the problem.

What it does not prove is that the publisher is trustworthy, or that the file is safe. A hash of malware matches the hash of that malware perfectly.

The problem with a hash on the same page

This is the part most guides skip.

If an attacker can replace the file on the download server, they can almost always replace the hash printed next to it. Same server, same compromise, same afternoon. You would compute the hash, compare it to the one on the page, see a match, and install the malicious file with more confidence than if no checksum had been offered at all.

So a checksum published on the same page as the download is protection against accidents, not against attackers. That is still useful — accidents are far more common than targeted attacks on your particular download — but it is worth knowing which risk you have actually covered.

When a checksum really does protect you

The hash becomes meaningful when it lives somewhere the attacker would have to compromise separately:

• A GPG-signed SHA256SUMS file — the signature is what carries the security. The hash tells you the file matches the list; the signature tells you the list came from the publisher and has not been edited. Verifying the hash without checking the signature does the easy half and skips the useful half.
• A different domain or infrastructure — a hash on the project’s GitHub release page for a file hosted on a third-party mirror.
• A package manager’s index — apt, Homebrew, npm and the rest verify hashes against a signed index as a matter of course. This is why installing through a package manager is generally safer than downloading an installer by hand.

If the page offers a signature file alongside the checksum, the signature is the thing actually worth verifying.

Running the check

On macOS and Linux, shasum is present almost everywhere:

shasum -a 256 ubuntu.iso

On most Linux distributions there is also a dedicated binary:

sha256sum ubuntu.iso

Both print the digest followed by the filename. On Windows, PowerShell has it built in:

Get-FileHash ubuntu.iso -Algorithm SHA256

PowerShell defaults to SHA-256, so the -Algorithm flag is optional — but state it anyway, because a guide that says “SHA256” and a command that silently picks something else is exactly how people end up comparing the wrong things.

Comparing the two values

Do not read 64 hex characters off the screen and compare them by eye. People check the first six characters and the last six, and that is precisely the comparison a crafted file would survive.

If the publisher provides a SHA256SUMS file, let the tool do it:

sha256sum -c SHA256SUMS

It prints ubuntu.iso: OK when the file matches, and on a mismatch prints FAILED, a warning, and exits non-zero — which matters if you are running this in a script. On macOS the equivalent is shasum -a 256 -c SHA256SUMS.

If all you have is a hex string on a web page, paste both values into something that compares them character by character. Note that published digests are often uppercase while command-line tools print lowercase; the values are the same, so compare case-insensitively rather than concluding you have a mismatch.

Which algorithm you will see

What the page offers	What to do
SHA-256	The normal case. Use it.
SHA-512	Fine, no practical difference for this purpose
MD5 or SHA-1 only	Usable against corruption, worthless against tampering
A signature file as well	Verify that instead — it is the part with teeth

The pattern is that the algorithm barely matters for catching a corrupted download; any of them will notice a flipped byte. It matters enormously the moment someone might be trying to make two files match on purpose, which is why MD5 is fine for one job and broken for the other.

What this tool can and cannot do

Worth saying plainly: Toolora’s hash generator hashes text you paste, not files you select. For checking a 5 GB ISO, the command line above is the right tool and a browser text box is not. We would rather tell you that than have you discover it after pasting a filename and wondering why the digest looks wrong.

Where it does help is the comparison step — paste the published digest and the one your terminal printed and see whether they actually match, instead of squinting at them. It is also useful for hashing a short string, checking a config value, or simply seeing what a SHA-256 digest looks like before you trust one.

It runs entirely in your browser, which matters here because the strings people paste into hash tools are often the ones they least want to send to a stranger’s server — API keys, config fragments, passwords they are about to check against a leak list.

Verifying a download costs about ten seconds. Reinstalling an operating system from an image that was quietly truncated costs considerably more.