How to Verify a File Checksum (SHA-256, MD5 and CRC-32)

A download page shows a long string of hex next to the file - something like sha256: e3b0c442... - and most people scroll past it. That string is a checksum, and comparing it against the file you actually received is the cheapest way to know your download arrived complete and unmodified. It takes about ten seconds. This guide covers how to produce a file's checksum on any operating system or in the File Checksum Calculator, how to read the formats publishers use, what to do when the numbers disagree, and the limit that matters: what a match does and does not prove.

What a checksum actually is

A checksum is the output of a hash function run over every byte of a file. Feed the same bytes in and you always get the same digest out; change a single bit and the digest changes completely. The publisher prints the digest of the file they meant to ship; you compute the digest of the file that arrived; if the two strings are identical, you have the same bytes they did.

The length of the digest tells you which algorithm produced it, which is useful because publishers do not always say:

• 8 hex characters (4 bytes) - CRC-32. Not a hash: an error-detecting code, the one stored inside zip, gzip and PNG files.
• 32 hex characters (16 bytes) - MD5.
• 40 hex characters (20 bytes) - SHA-1.
• 64 hex characters (32 bytes) - SHA-256. The current default, and the one to prefer.
• 128 hex characters (64 bytes) - SHA-512. Debian publishes these; so do a number of enterprise vendors.

A digest is occasionally handed to you in Base64 rather than hex - S3 and Azure both report MD5 that way in a Content-MD5 header. It is the same value written differently.

Reading the formats publishers use

There are three common ways to write a checksum down:

• A bare digest, printed on the download page next to the file.
• A coreutils line, which is what a SHA256SUMS file holds: the digest, two spaces, then the filename - or a space and an asterisk, meaning the file was read in binary mode. The asterisk is not part of the name.
• The BSD style, used by macOS and FreeBSD tools: SHA256 (ubuntu-24.04.iso) = e3b0c442...

A release often ships one SHA256SUMS file covering every image it publishes. Download that rather than copying a single value, so the desktop ISO is checked against the desktop line instead of whichever of six similar hex strings you picked out by eye.

Checking a file in the browser

Drop the file into the File Checksum Calculator and it computes SHA-256, SHA-1 and MD5, with SHA-512 and CRC-32 as tick boxes. Nothing is uploaded: the file is read off your disk in four-megabyte chunks, each folded into the running digest and discarded, so a 4 GB ISO costs time but not memory.

Then paste what the publisher gave you into the compare box. It takes any of the three formats above, a Base64 digest, or the whole SHA256SUMS file - in which case each file you dropped in is matched to the line filed under its name. The algorithm is inferred from the digest's length, and the comparison is on bytes, so a digest in capitals matches one in lowercase rather than reading as a mismatch.

You can also drop two files in with no published checksum at all: if their SHA-256 digests agree they are byte-for-byte identical, which is the quickest way to confirm a copy or a backup came through intact.

Checking a file from the command line

Every operating system ships a tool for this:

• Linux: sha256sum file.iso, or sha256sum -c SHA256SUMS to check every file a sums file lists at once. md5sum and sha1sum work the same way.
• macOS: shasum -a 256 file.iso, or shasum -a 512 for SHA-512. Also md5 file.iso, which prints the BSD style.
• Windows PowerShell: Get-FileHash file.iso -Algorithm SHA256. It prints capitals, which is not a difference in value.

The command line is faster on a large file - those tools use native code and often the CPU's own SHA instructions. The browser wins when you would rather not install anything, or want several algorithms in one pass.

A worked example

Make a file holding exactly the five bytes of the word hello, no newline: printf 'hello' > hello.txt. Its checksums are:

• MD5: 5d41402abc4b2a76b9719d911017c592
• SHA-1: aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
• SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
• CRC-32: 3610a686

Now make the same file the way almost everyone would: echo hello > hello.txt. That writes six bytes, because echo adds a trailing newline. The SHA-256 is now 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 - not similar to the previous value, not close to it, simply unrelated. One invisible byte in five has changed every character of the digest.

That is the avalanche effect, and it is what makes checksums useful: there is no such thing as a near miss. Two digests either match exactly or tell you nothing at all about how alike the files are.

When the checksum does not match

Work through this in order, because the boring explanations are overwhelmingly the likely ones:

1. Check the file size against the download page. A truncated or interrupted transfer is by far the most common cause, and the size usually gives it away.
2. Check you are on the right line. A release page lists several images - desktop and server, amd64 and arm64 - and one will never match another.
3. Check the algorithm: a SHA-256 digest compared against a published SHA-512 can never match, and the lengths disagreeing is the clue.
4. Download it again from a different mirror and check once more. A bad mirror or a flaky connection accounts for most genuine mismatches.
5. If a fresh copy from a second source still disagrees, stop. Do not run it, do not install it, and report it to the project.

A matching checksum is not a signature

This is the part most tutorials skip. A checksum proves the file you hold is the file that was hashed. It says nothing about who did the hashing.

An attacker who can replace the download can almost always edit the page printing the checksum beside it. Recomputing the digest of their own tampered file takes a second, and every verification after that succeeds. The check defends against accidents - corrupt disks, truncated transfers, stale mirrors - and against an attacker who controls the file but not the page.

What defeats a deliberate substitution is a signature over the checksums, verified against a key you already trust: a SHA256SUMS.gpg checked with gpg --verify against a project key you obtained separately, or the vendor's own code signature. Debian and Tails publish exactly this, and their instructions tell you to fetch the signing key from somewhere other than the download page for precisely this reason. Against a bad download, a checksum is enough. Against someone who wants you to run their file, it is not.

Which algorithm to use for your own files

If you are the one publishing, use SHA-256. MD5 and SHA-1 are broken for collision resistance - two different files with the same digest can be constructed, in seconds on a laptop for MD5. They still catch a corrupted download, which is why so much software lists them, but they cannot support a claim that a file is genuine. CRC-32 is weaker again: matching a chosen value takes four adjusted bytes. For why MD5 fell, see MD5 vs SHA-256.