How to check a file against its checksum

A checksum is a short fingerprint of a file's exact bytes. The publisher works it out from the file they released and prints it on the download page. You work it out from the file you got. If the two are the same, every byte arrived as it was sent. If one byte is different, the whole fingerprint is different.

shasum -a 256 -c --ignore-missing SHA256SUMS      # macOS
sha256sum -c --ignore-missing SHA256SUMS          # Linux

A real example

To show what each result looks like, here is the Node.js 24.22.0 release. Its download folder, https://nodejs.org/dist/v24.22.0/, holds 33 files and one SHASUMS256.txt listing a SHA-256 for each of them, one per line:

00e9f08b9057f9f5428387a5ffd496e53f274565b40b144b7ba876700755352a  node-v24.22.0-headers.tar.gz
23485102f0159fe0aa9a485840f35ce59300a765542b71af1ecdb1f2272ef4f8  node-v24.22.0-headers.tar.xz

That is the format sha256sum and shasum write and read: the digest, two spaces, the file name. We downloaded SHASUMS256.txt and the smallest file in the release, node-v24.22.0-headers.tar.xz (581,516 bytes), into one folder.

Why --ignore-missing

A checksum file usually lists every file in the release, and you downloaded one. Without the option, the command reports each file you don't have as a failure and exits with an error, which buries the one line you care about:

shasum: node-v24.22.0-aix-ppc64.tar.gz: No such file or directory
node-v24.22.0-aix-ppc64.tar.gz: FAILED open or read
...
shasum: WARNING: 33 listed files could not be read

Your file's OK is in there, but --ignore-missing is the clean way to say "only check what I have".

When there is no checksum file, only a string

Many download pages print the digest in the text instead. Work out your own and compare:

shasum -a 256 node-v24.22.0-headers.tar.xz        # macOS
sha256sum node-v24.22.0-headers.tar.xz            # Linux

23485102f0159fe0aa9a485840f35ce59300a765542b71af1ecdb1f2272ef4f8  node-v24.22.0-headers.tar.xz

Comparing 64 characters by eye is where mistakes happen. Let the computer do it: build the line yourself, with the published digest, two spaces and the file name, and pipe it into the check:

echo "23485102f0159fe0aa9a485840f35ce59300a765542b71af1ecdb1f2272ef4f8  node-v24.22.0-headers.tar.xz" | shasum -a 256 -c

node-v24.22.0-headers.tar.xz: OK

What a mismatch looks like

We changed a single bit in a copy of the same file, one byte out of 581,516, and checked it again:

node-v24.22.0-headers.tar.xz: FAILED
shasum: WARNING: 1 computed checksum did NOT match

Its SHA-256 was now da4534111f1ce41364301b390f5377a24e48e71d4b02cc97cfe8a0b1c7dd63dd, nothing like the 23485102… it should be. That is how hashes are designed: one changed bit and the whole digest changes. So a mismatch doesn't tell you how much of the file is wrong, only that it isn't the right file. If the two digests are almost the same, with a character or two different, the file isn't nearly right: the digest was copied wrongly.

When you see FAILED, check in this order:

• Is it the right file? Same version, same platform, same format. The two lines above are for the .tar.gz and the .tar.xz of the same release.
• Did the download finish? Compare the file size with the one on the page, then download it again.
• Is it the right algorithm? A 64-character digest is SHA-256; 128 is SHA-512; 32 is MD5. Run the command that matches.

If a fresh download from the official page still fails, don't open it.

"no file was verified"

This one means the check never ran. The names in the checksum file must match the names on disk exactly, and a browser that already had a copy saves the new one as node-v24.22.0-headers (1).tar.xz. With --ignore-missing, that file is simply not listed, so there is nothing to check:

shasum: SHASUMS256.txt: no file was verified

Rename the file back to the name in the checksum file, or delete the old copy, and run it again.

On Windows

Windows has two built-in ways. We could not run these on Windows for this guide, so the commands below follow Microsoft's own documentation.

In PowerShell, Get-FileHash uses SHA-256 unless you name another algorithm (-Algorithm SHA512, MD5 and so on):

Get-FileHash .\node-v24.22.0-headers.tar.xz | Format-List

Without | Format-List the result is a table, and in a narrow window PowerShell 7 cuts the hash off with … to make it fit. With it, you get the algorithm, the whole hash in uppercase and the path:

Algorithm : SHA256
Hash      : 23485102F0159FE0AA9A485840F35CE59300A765542B71AF1ECDB1F2272EF4F8

To let PowerShell compare it with the published digest, the way Microsoft's own example does:

(Get-FileHash .\node-v24.22.0-headers.tar.xz).Hash -eq "23485102f0159fe0aa9a485840f35ce59300a765542b71af1ecdb1f2272ef4f8"

It prints True or False. The uppercase output against the lowercase published digest doesn't matter here: PowerShell's -eq ignores case for text. We ran both lines in PowerShell 7.4.2 on Linux, where the cmdlet is the same, and got True for the real file and False for the damaged copy.

In Command Prompt, certutil -hashfile prints the digest of a file. Always name the algorithm:

certutil -hashfile node-v24.22.0-headers.tar.xz SHA256

Neither reads a SHA256SUMS file. Find your file's line in it and compare against that, or paste the line into the Hash Generator.

In the browser

You don't choose the algorithm: the tool works it out from the length of what you paste, so a SHA-256 can't be compared with an MD5 by mistake. Case, spaces and colons between the pairs are ignored.

Two limits worth knowing:

• Paste one line, not the whole checksum file. A whole SHASUMS256.txt has a digest for every file, and the tool can't know which one is yours, so it says it can't read it rather than guess. Copy your file's line.
• Above 64 MB, SHA-384 and SHA-512 are not worked out. MD5, SHA-1 and SHA-256 still are, read in chunks so the browser doesn't need to hold the whole file. Most projects publish SHA-256, so this rarely matters. The other two rows show a dash and the reason, never a wrong number.

What a match proves, and what it doesn't

A match proves the file you have is byte for byte the file the checksum was made from. That catches a download that broke off, a copy damaged on a USB stick, or a mirror serving the wrong version.

It doesn't prove who made the file. If someone can change the file on the download site, they can usually change the checksum printed next to it too, and the two will match perfectly. A checksum is worth most when it comes from somewhere other than the file: the file from a mirror, the checksum from the project's own site.

To know the checksum file itself is genuine, the project has to sign it. Node.js does: next to SHASUMS256.txt are SHASUMS256.txt.sig and SHASUMS256.txt.asc, made with the release team's keys. Verify that signature first, then check your file against the list. That is in how to verify a signed file or release.

Which to use

• macOS or Linux, with a checksum file: shasum -a 256 -c --ignore-missing or sha256sum -c --ignore-missing. One command, and it compares for you.
• Windows: Get-FileHash with -eq, or the Hash Generator if you want the checksum line read for you.
• A phone, a Chromebook, or one file and a string on a web page: the Hash Generator.

When it says OK, True or Match, the file is the one the project published. Open it.