How to Verify File Integrity with SHA-256

Why verify at all

When you download an installer or a system image, the vendor usually publishes a SHA-256 value. Comparing it confirms two things: the file was not corrupted in transit and was not tampered with.

Three steps

1. Find the published SHA-256 value on the official page — do not compare against their MD5 or SHA-1 value.
2. Compute the SHA-256 of the file you actually have.
3. Compare character by character; it must match exactly.

The three most common pitfalls

• Wrong algorithm: the vendor published both MD5 and SHA-256 and you compared the wrong one.
• Untrusted source: if the download page was hijacked, the published value is fake too. Prefer HTTPS official sources.
• "Close enough" thinking: a hash must match exactly; one differing character means a different file.

Computing locally in the browser

The browser Web Crypto API keeps the file on your device: fast, and never exposes the installer to a third party. Larger files take proportionally longer.

Command cheat sheet

Checksums vs digital signatures

A checksum proves the file did not change, but not that it came from the vendor — the value lives on the same website, so a compromised site invalidates the comparison. A digital signature (GPG or a code-signing certificate) is verified with a public key and proves integrity and origin. For system images and packages, check signatures.

Mismatch, but the file works?

• Confirm which file the published value belongs to — the same name often ships for several architectures (x64 / arm64);
• Confirm the download completed and was not truncated by a browser or proxy (compare sizes);
• Confirm no stray spaces, line breaks or case differences slipped into the comparison;
• If everything is ruled out and it still mismatches — do not install it; re-download from the official source.

Batch and automation

When several files need checking, put "expected hash + file path" into a list and let a script compute and compare each one, printing a pass/fail table instead of comparing by eye:

# values.txt: one "expected-hash file-path" per line
while read -r expect file; do
  actual=$(sha256sum "$file" | awk '{print $1}')
  [ "$expect" = "$actual" ] && echo "OK   $file" || echo "FAIL $file"
done < values.txt

For continuous delivery, emit the hash list when artefacts are built and compare automatically before deployment — move verification earlier in the pipeline.

Try them: file hash checker (drop a file), hashing (text)

Organising the verification flow

The value of a checksum comes from being part of a process, not from a one-off run.

1. Keep checksums separate: publish the value somewhere other than beside the file, such as an official announcement page, so the two cannot be replaced together.
2. Generate during build: the checksum manifest should come from the build pipeline and be archived with the release; hand-computed values are error-prone and hard to reproduce.
3. Verify before deployment: deployment scripts should check after download and abort on mismatch rather than failing later with a cryptic error.
4. Record the results: log and monitor both passes and failures — persistent failures usually mean a stale mirror or tampering in transit.
5. Spot-check periodically: re-verify long-untouched artefacts to confirm storage has not corrupted or replaced them.

Checksum versus signature

A checksum answers "is the file what we expect"; a signature answers "is the publisher who they claim". They work together: verify the signature to establish origin, then the checksum for integrity. Either alone can fail against a supply-chain attack.

Extra advice for archives

Long-term archives deserve periodic integrity scans: compare current checksums with the recorded values to catch media ageing or migration damage early. Set the cadence by media reliability and data value, and do not skip it even on cheap storage.