Learn · Practical guides

How to verify a download's SHA-256 checksum

The Windows, Mac and Linux commands for checking a download against a published SHA-256, how to read a SHA256SUMS file, and why a signature proves more.

By B Klug (GitHub) · Oct 23, 2026 · 6 min read

To check that a file you downloaded is the right one, compute its SHA-256 checksum and compare it with the one the publisher lists. On Windows run certutil -hashfile file.iso SHA256 (or Get-FileHash file.iso in PowerShell). On a Mac run shasum -a 256 file.iso, and on Linux run sha256sum file.iso. If the 64 characters match the published value, you have the file that was listed. You can also drop the file into the file checksum verifier below, which works in your browser, reads a whole SHA256SUMS file and checks many files at once.

Checksum or a whole SHA256SUMS file

Drop one or many files here, or click to choose. They are checked as they arrive.

Algorithm

Nothing you paste or drop here leaves your browser. Files are read in pieces by a background worker, so a 4 GB ISO is fine.

The commands, system by system

Windows

Open Command Prompt or PowerShell in the folder with the file and run either of these. Both ship with Windows, so there's nothing to install.

Command Prompt or PowerShell. The long string is the checksum (here, the well-known one for the three letters abc, for illustration).

certutil -hashfile ubuntu.iso SHA256

SHA256 hash of ubuntu.iso:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
CertUtil: -hashfile command completed successfully.

PowerShell (illustrative output). The hash is shown in capitals; capitals and lower case are the same value.

Get-FileHash .\ubuntu.iso -Algorithm SHA256

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD       C:\Users\you\ubuntu.iso

PowerShell can do the comparison for you too: (Get-FileHash .\ubuntu.iso).Hash -eq "ba7816bf…" prints True or False, and ignores case. SHA-256 is the default for Get-FileHash; add -Algorithm SHA512 or SHA1 for others.

macOS

Terminal. Output copied from a real run on a file holding the three letters abc.

shasum -a 256 abc.txt
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  abc.txt

openssl dgst -sha256 file does the same, and on recent versions prints SHA2-256(abc.txt)= ba78… on recent versions (older ones write SHA256(abc.txt)= …). Drag the file into the Terminal window after typing the command to fill in its path.

Linux (and WSL)

Any distribution. sha256sum is part of GNU coreutils.

sha256sum abc.txt
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  abc.txt

Checking against a SHA256SUMS file

Projects often publish one text file listing the checksum of every download, usually called SHA256SUMS. Each line is a hash, then two spaces (or a space and an asterisk, for binary mode), then the file name. Put it in the same folder as the downloads and let the tool do the comparing, so you aren't checking 64 characters by eye:

On a Mac use shasum -a 256 -c SHA256SUMS: it prints the same OK and FAILED lines (copied from a real run). Add --ignore-missing (GNU) when you downloaded only some of the listed files.

sha256sum -c SHA256SUMS
abc.txt: OK

# if the file was changed:
abc.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

The BSD style, SHA256 (file) = hash, is read by recent GNU sha256sum -c too, and by the verifier above, which reads both. A line that says FAILED means the file you have isn't the file that was listed. Don't run or install it. Download it again, ideally from another mirror, and check again.

Reading the result

Every character must match. One different character means a different file. A hash doesn't tell you "how different", because changing one bit of the file gives a completely unrelated hash (hash functions).
Same algorithm. A SHA-256 value is 64 hex characters, a SHA-1 40, an MD5 32 and a SHA-512 128. Compare like with like. The verifier detects the algorithm from the length.
Same file. The checksum of a .zip isn't the checksum of the folder inside it. Check the exact file you downloaded, before you unpack it.
A match isn't a stamp of safety. It says "this is the file the publisher listed", and nothing about whether the publisher, or the page, is trustworthy.

Why a checksum from the same website proves less than you'd hope

A checksum catches accidents, like a download cut short, a damaged disk or a flaky mirror. It does not protect you from an attacker who has replaced both the file and the checksum, because they can compute a new checksum as easily as you can. If the file and its checksum come from the same server over the same connection, anyone who controls the server controls both. A checksum is only as trustworthy as the channel it arrived by. That's why serious projects also publish a signature, which a thief can't forge without a private key kept elsewhere:

GPG (OpenPGP). The project signs the checksum file or the download with its private key and publishes a .sig or .asc file. You fetch the project's public key, check its fingerprint through a second route (the project's site over HTTPS, a keyserver, a person you trust), and run gpg --verify SHA256SUMS.sig SHA256SUMS. "Good signature" from the expected key means the file came from whoever holds that key. The sticking point is getting the right key.
minisign. A small modern tool by Frank Denis with short keys, run as minisign -Vm file -P <public key>. The public key is a short string you can copy from the project's documentation. It has fewer features than GPG, and that's the point.
sigstore (cosign). Instead of a long-lived key, it records who signed (a login identity, such as an account at an identity provider) in a public transparency log. To verify, you tell cosign verify-blob which identity and issuer to expect, and the project's documentation gives the exact command for its releases.

If the project offers a signature, verify it too. If it offers only a checksum, one fetched over HTTPS from the project's own site is still much better than none, while a checksum copied from a forum post or a mirror's page is worth little.

How cipher.ink uses checksums

The site's tools make no network requests while you use them, so a checksum check here runs entirely in your browser. A background worker reads a 4 GB ISO in pieces, and nothing is uploaded. We test the algorithms against the official vectors on every deploy, and the hash generator and hash comparer use the same engine. SHA-256 is the one to use for new checksums. MD5 and SHA-1 are broken for security purposes and fine only for catching accidents.

Common questions

The checksums don't match. What now?

First check that you're comparing the right file and the right algorithm. Then download again, preferably from another mirror, and compare again. A repeated mismatch from the official site means the page or the file changed after the checksum was published. Don't use the file, and tell the project.

Can I trust MD5 or SHA-1 checksums?

They still catch accidental damage. They don't protect against deliberate tampering, because attacks that make two different files with the same MD5 or SHA-1 exist. Prefer SHA-256 when the choice is yours.

Why does the checksum take so long for a big file?

The whole file has to be read once. A modern computer manages hundreds of megabytes per second for SHA-256, so a 4 GB image takes anywhere from seconds to a minute, depending mostly on how fast the disk is.

Is it safe to use an online tool for this?

Only one that does the work in your browser and doesn't upload the file. This one makes no requests while you use it, which our tests check. A tool that uploads the file asks you to trust a third party with it and gains you nothing.