Skip to the tool workspace
Browser 123

How-to Keys and encryption

How to check a file against its checksum

Confirm a download is exactly the file the publisher released: the one command on macOS, Linux and Windows, how to read a SHA256SUMS file, what a mismatch means, and what a checksum can't prove.

BrowserBasedTools 9 min read Built-in first

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.

The Hash Generator with report.pdf loaded: its checksums, each with a Copy button, and under Compare against a pasted sha256sum line with the verdict Match

Paste the line from the download page and the tool picks the right digest and says Match.

The direct wayshasum · sha256summacOS · Linux

Put the checksum file the project publishes in the same folder as the download, then let the command do the comparing:

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

For each file you have, it prints the name and OK, or FAILED. Both commands are already installed. Use the name of the checksum file you downloaded: projects call it SHA256SUMS, SHASUMS256.txt, sha256sum.txt or similar.

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.

Check a download on macOS or Linux

  1. Download the file and the checksum file from the project's own download page, into the same folder.

  2. Open Terminal in that folder (cd ~/Downloads).

  3. Run the check with --ignore-missing:

    shasum -a 256 -c --ignore-missing SHASUMS256.txt

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

    On Linux the command is sha256sum -c --ignore-missing SHASUMS256.txt, with the same output.

  4. OK is the answer. Any FAILED line means that file is not the one the project listed.

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

  1. Open the Hash Generator and drop the downloaded file on it, or choose it. It works out MD5, SHA-1, SHA-256, SHA-384 and SHA-512 together, straight away.
  2. Paste the checksum into Compare against. It takes a bare digest, a sha256sum or shasum line with the file name still on it, BSD md5 output, or a certutil block as Windows prints it.
  3. Read the verdict: Match, or No match with both digests shown one above the other so you can see where they differ.

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.

The Hash Generator with report.pdf loaded and a different file's sha256sum line pasted under Compare against: the verdict No match, then You pasted and Computed here with two different SHA-256 digests one above the other

No match shows both digests, so a copying error and a different file are easy to tell apart.

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.

MD5, SHA-1 and SHA-256

All three catch accidental damage. The difference is deliberate forgery: two different files with the same MD5 have been made since 2004, and with the same SHA-1 since 2017. No such pair has ever been found for SHA-256. When a page lists several, check the SHA-256 (or SHA-512).

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.

Questions people ask

The checksums don't match. Is the file malware?

Usually not. The common causes are a download that stopped early, the wrong file (another version, another platform, or the .tar.gz when the line is for the .tar.xz), or comparing against the wrong algorithm. Download it again from the official page and check again. If a fresh copy from the official site still doesn't match the checksum on that site, don't run it, and tell the project.

Is MD5 or SHA-1 still good enough?

For catching a damaged download, yes: an accidental change still gives a different digest. Against someone deliberately making a file to match, no. Different files with the same MD5 have been made since 2004, and with the same SHA-1 since 2017. If the publisher lists SHA-256 as well, use that.

Do uppercase and lowercase matter?

No. A digest is a number written in hexadecimal, so A and a are the same digit. PowerShell prints uppercase and shasum prints lowercase for the same file. What matters is every character, in order. The Hash Generator also ignores spaces or colons between the pairs; sha256sum and shasum want the digest as one unbroken string.

Is it enough to compare the first and last few characters?

For an accidental error it nearly always is, because one changed byte changes the whole digest. Against a deliberate attacker it isn't: a file that matches the first and last eight characters can be found with ordinary computing power. Let the command or the tool compare the full string.

Can I check a checksum on my phone?

Neither iOS nor Android has a built-in way to do it. The Hash Generator works in the phone's browser: choose the downloaded file, paste the checksum, and it says Match or No match. The file is read on the phone and not uploaded.

Tools in this guide

Everything runs on your device

Hash Generator

All guides

/
123 items
Runs in your browser·Your files stay on this device
Out0 B
Ready—
Privacy · Terms