How to Verify a SHA-256 Checksum on Windows, macOS and Linux (and What It Actually Proves)

Published by the team behind Nibbo (https://nibbo.org), a set of free in-browser tools.

Download pages for Linux ISOs, CLI tools, firmware and password managers all list a long hex string next to the file: SHA256: 9f86d081884c7d65.... Most people scroll past it. It takes about 20 seconds to check, and it's worth knowing exactly what that check protects you from.

What a checksum proves

A cryptographic hash (SHA-256 here) turns any file into a fixed-length fingerprint. Change one bit of the file and the fingerprint changes completely.

Comparing your file's hash with the published one tells you:

• ✅ The download isn't corrupted (flaky Wi-Fi, a truncated transfer, a bad mirror).
• ✅ The file is the same one the publisher hashed.

What it does not prove on its own:

• ❌ That the publisher is trustworthy.
• ❌ That the hash itself wasn't swapped. If an attacker controls the download page, they can replace the file and the hash together.

That's why serious projects also sign the checksum file (GPG, minisign, Sigstore). The hash checks integrity; the signature checks authenticity. Still, checking the hash catches the most common real-world problem: broken or tampered mirrors.

Windows

PowerShell has it built in:

Get-FileHash .\installer.exe -Algorithm SHA256

Or in cmd:

certutil -hashfile installer.exe SHA256

macOS

shasum -a 256 ~/Downloads/installer.dmg

Linux

sha256sum ubuntu-24.04-desktop-amd64.iso

If the project ships a SHA256SUMS file, let the tool compare for you:

sha256sum -c SHA256SUMS --ignore-missing

You want to see OK next to your file name.

No terminal? Do it in the browser, locally

Sometimes you're on a locked-down work laptop or helping a relative over the phone. The hash generator in Nibbo computes MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3 and Keccak-256 of a dropped file and has a field to paste the expected hash for comparison. The file is read in chunks by JavaScript in the page; it isn't uploaded, which matters when you're hashing a 6 GB ISO or a confidential archive.

Comparing without squinting

Humans are bad at comparing 64 hex characters. Don't eyeball the first and last four. Use the tool's comparison, or in PowerShell:

(Get-FileHash .\file.zip).Hash -eq "PASTE_EXPECTED_HASH".ToUpper()

Watch out for case: Windows prints uppercase hex, most websites publish lowercase. Hashes are case-insensitive, string comparisons aren't.

MD5 and SHA-1?

Both are broken for security purposes: collisions can be crafted. They're still fine for detecting accidental corruption (some old mirrors only publish MD5), but if SHA-256 is available, use it.

Bonus: hashes in your own projects

• Publish a SHA256SUMS file alongside release artifacts; GitHub Actions can generate it in one step.
• Use Subresource Integrity (integrity="sha384-...") for scripts loaded from a CDN.
• When you need to embed a small binary in JSON or a data URL, Base64 is the encoding. Remember it's not encryption and not a hash.

TL;DR

Get-FileHash, shasum -a 256, or sha256sum: compare with the published value, preferably from a signed checksum file. Twenty seconds, and you'll never debug a "corrupted installer" again.

— Vitalii, author of Nibbo