How to Verify a Downloaded File's Checksum (Step by Step)

Updated on June 5, 2026

You just downloaded a 2 GB Linux ISO or a new release of some CLI tool you rely on. The project's release page lists a SHA-256 checksum right below the download link. Most people skip this step entirely — and that's a shame, because it takes under sixty seconds and it's the difference between knowing your file is exactly what the author shipped versus hoping it is.

This guide walks you through the whole thing, on macOS, Linux, and Windows, using only tools that are already on your machine. No extra software needed.

What a checksum actually tells you

A SHA-256 hash is a 64-character hex string produced by running a file through a mathematical function. Change even a single byte in the file — whether from a corrupted download, a man-in-the-middle swap, or a supply-chain compromise — and the hash output changes completely. When you compare your locally computed hash against the one the developer published (ideally on a separate domain or signed with GPG), you're confirming two things at once: the file arrived intact and it matches what was actually released.

One important caveat: a checksum alone doesn't prove the developer's site wasn't compromised. For high-stakes software, you should also verify a GPG signature. But for the vast majority of everyday downloads, SHA-256 verification is a solid and practical first line of defense.

Step 1 — Find the official checksum

Before you compute anything locally, you need the reference hash to compare against. Look for it on the project's official release page, not in the downloaded archive itself (an attacker could tamper with both). It's usually labeled something like SHA256SUMS, checksums.txt, or just printed inline next to each download link.

Copy the 64-character string for the exact filename you downloaded. Keep it on your clipboard or paste it into a text editor — you'll use it in a moment.

Step 2 — Open a terminal (or PowerShell)

Navigate to the folder where the file landed. If it went to your default downloads folder:

  • macOS / Linux: cd ~/Downloads
  • Windows: cd $env:USERPROFILE\Downloads in PowerShell

Step 3 — Compute the hash

macOS

macOS ships with shasum, which covers every SHA variant. The -a 256 flag picks SHA-256:

shasum -a 256 yourfile.iso

You'll see output like this after a few seconds (or a few minutes for large files):

b94d27b9934d3e08a52e52d7da7dabfac484efe04294e576e732b6d3f2b5c4f  yourfile.iso

If you also have OpenSSL installed (it's built in on modern macOS), the equivalent is:

openssl dgst -sha256 yourfile.iso

Linux

On virtually every Linux distro, sha256sum is part of the coreutils package and is almost certainly already installed:

sha256sum yourfile.tar.gz

Same output format — hash, two spaces, filename. Some projects ship a full SHA256SUMS file listing every release artifact. If you downloaded that file alongside your archive, you can verify automatically:

sha256sum -c SHA256SUMS

This checks every line in the file and prints OK next to each one that matches. If your file is the only one you downloaded, you'll see a warning about missing files — that's fine, just look for your filename's result.

Windows (PowerShell)

Windows 10 and 11 include Get-FileHash as a built-in PowerShell cmdlet. No installation needed:

Get-FileHash .\yourfile.exe -Algorithm SHA256

The output comes back in a table:

Algorithm  Hash                                                              Path
---------  ----                                                              ----
SHA256     B94D27B9934D3E08A52E52D7DA7DABFAC484EFE04294E576E732B6D3F2B5...  .\yourfile.exe

Note that PowerShell outputs the hash in uppercase while most Linux/macOS tools output lowercase. That doesn't matter — the comparison is case-insensitive.

Step 4 — Compare the hashes

Now you need to check whether what you computed matches what the project published. The naive approach — eyeballing 64 hex characters — is error-prone. Here are better methods for each platform.

macOS / Linux — inline comparison

The cleanest trick is to use echo and pipe both values into a simple diff. Replace the hash below with the one you copied from the project site:

echo "b94d27b9934d3e08a52e52d7da7dabfac484efe04294e576e732b6d3f2b5c4f  yourfile.iso" | sha256sum -c

On macOS with shasum:

echo "b94d27b9934d3e08a52e52d7da7dabfac484efe04294e576e732b6d3f2b5c4f  yourfile.iso" | shasum -a 256 -c

A clean result prints: yourfile.iso: OK

A mismatch prints: yourfile.iso: FAILED — and you should delete the file immediately and re-download from the official source.

Windows — PowerShell string comparison

$expected = "b94d27b9934d3e08a52e52d7da7dabfac484efe04294e576e732b6d3f2b5c4f"
$actual   = (Get-FileHash .\yourfile.exe -Algorithm SHA256).Hash.ToLower()
if ($actual -eq $expected) { "MATCH — file is good" } else { "MISMATCH — do not use this file" }

Paste this as a block into PowerShell, substituting your expected hash and filename. The .ToLower() call normalises the case so uppercase/lowercase differences don't produce false failures.

Step 5 — Interpret the result and act on it

Hashes match: You're done. The file is byte-for-byte identical to what the developer uploaded. Go ahead and install or extract it.

Hashes don't match: Stop. Don't open or run the file. Possible causes:

  • The download was interrupted and the file is incomplete — the most common culprit by far. Try downloading again.
  • You accidentally grabbed the hash for a different file (e.g., the ARM build instead of x86). Double-check you're comparing the right hash.
  • The file was genuinely tampered with. This is rare but real — it has happened with popular tools like HandBrake and CCleaner.

If a fresh download still fails, check whether the project has an announcement about a compromised mirror or a release issue. Report it to the maintainers.

A faster workflow for repeat use

If you verify checksums regularly — which you should, especially for developer tools, language runtimes, and security software — a tiny shell function saves a lot of typing. Add this to your ~/.zshrc or ~/.bashrc:

checksum() {
  local file="$1"
  local expected="$2"
  local actual
  actual=$(shasum -a 256 "$file" | awk '{print $1}')
  if [ "$actual" = "$expected" ]; then
    echo "OK — $file matches"
  else
    echo "FAIL — expected: $expected"
    echo "       got:      $actual"
  fi
}

Usage: checksum yourfile.iso b94d27b9934d3e08...

No more copy-paste gymnastics between two terminal windows.

Beyond SHA-256: when you'll see MD5 or SHA-1

Older projects still publish MD5 or SHA-1 checksums. These are cryptographically broken — meaning it's theoretically possible (and for MD5, practically feasible) to craft a malicious file that produces the same hash as a legitimate one. For integrity checking of downloads over HTTPS from a trusted source, MD5 is still better than nothing, but treat it as a weak signal. If a project is still using MD5 checksums in 2024, that's a mild red flag about its security hygiene overall.

For macOS: md5 yourfile or shasum -a 1 yourfile for SHA-1.
For Linux: md5sum yourfile or sha1sum yourfile.
For Windows: Get-FileHash .\yourfile -Algorithm MD5

One more thing: where to get the checksum

This is worth repeating because it matters more than the technical steps. The checksum is only useful if you fetched it from a trustworthy source that's separate from the download itself. In rough order of trustworthiness:

  1. The project's official GitHub Releases page (hardest to compromise silently)
  2. The project's own domain, served over HTTPS
  3. A third-party package manager that signs packages (Homebrew, apt with trusted keys, etc.)
  4. A random mirror site (lowest trust — avoid if possible)

Verifying a checksum that came from the same compromised server as the file itself gives you false confidence. The separate-source principle is what makes the whole thing work.

Once this becomes habit — and it really does become fast habit — you'll wonder how you ever installed software without it.