Verify File Integrity with SHA-256

The corrupted download

You just downloaded a 2 GB Linux ISO. You write it to a USB drive, boot your machine, and it fails with cryptic errors an hour into the installer.

The likely culprit: a single flipped bit during download. A broken mirror, a flaky connection, or a proxy that truncated the stream can corrupt a file that otherwise looks fine.

This is what checksums exist for. A SHA-256 hash is a fingerprint of the file: any change to the input, however small, produces a completely different hash. Verify the fingerprint before you use the file, and the failure mode disappears.

What is SHA-256?

SHA-256 is a cryptographic hash function standardized in FIPS 180-4. It takes any input - text, files, firmware - and produces a fixed 64-character hexadecimal digest.

Three properties make it right for integrity checking: it is deterministic (same input, same output), one-way (you cannot recover the input from the digest), and avalanche-sensitive (changing one bit changes roughly half the output bits).

A matching hash proves the file is byte-for-byte identical to what the publisher hashed. It does not, by itself, prove who hashed it or that the checksum was not tampered with - that is what signed checksums add.

Where SHA-256 is used

SHA-256 appears everywhere in modern computing:

• Software distribution - Linux distributions publish SHA-256 hashes for all ISO and package downloads
• Package managers - npm, pip, and apt verify artifact integrity
• Git version control - commits and objects are identified by SHA-1 (with SHA-256 object format now supported)
• SSL/TLS - certificates are fingerprinted with SHA-256
• Backup systems - deduplication and integrity checks
• Blockchain - Bitcoin uses SHA-256 to link blocks

How to verify file integrity

1. Get the expected hash from the official website, over HTTPS - never from forums, mirrors, or search results.
2. Generate the hash of your downloaded file, using a browser tool or one of the commands below.
3. Compare the two values character by character, or with a compare field built into the tool.
4. If they match, use the file. If they do not match, delete the file and download it again from an official mirror.
5. For high-value downloads, additionally verify the checksum file's GPG signature (see below).

SHA-256 commands by platform

Here is how to generate SHA-256 hashes on different platforms:

Get-FileHash filename.iso -Algorithm SHA256
# Or using certutil:
certutil -hashfile filename.iso SHA256

sha256sum filename.iso
# Or on Mac without sha256sum:
shasum -a 256 filename.iso

async function hashFile(file) {
  const buffer = await file.arrayBuffer();
  const hashBuffer = await crypto.subtle.digest('SHA-256', buffer);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

Verifying against a checksums file

Instead of copying a hash from a web page, you can download the distribution's checksums file - typically named SHA256SUMS - and verify all your files in one command.

The file lists hash + filename pairs. The -c (check) mode reads that file, hashes each listed file, and reports OK or FAILED for every entry.

This is both faster and safer than eyeballing hashes, because the comparison is exact and covers every file at once.

# Download the checksums file next to your ISO, then:
sha256sum -c SHA256SUMS
# Expected output for each listed file:
# ubuntu-24.04-desktop-amd64.iso: OK

Signed checksums: defending the checksum itself

A checksum is only as trustworthy as its source. If an attacker can replace the ISO on a mirror, they can replace the SHA256SUMS file next to it too - so a checksum from an untrusted source proves nothing.

Major distributions therefore sign the checksums file with GPG. The workflow: import the distribution's official signing key (over HTTPS), verify the signature on SHA256SUMS, and only then trust the hashes inside it.

This turns a single point of failure into two verifiable steps: the signature proves the checksums came from the publisher, and the checksums prove the files came from the publisher.

# Example with Ubuntu-style releases (adjust filenames per distribution)
gpg --verify SHA256SUMS.gpg SHA256SUMS
sha256sum -c SHA256SUMS

Automating checksum verification

For teams and power users, verification belongs in the pipeline, not in memory:

CI jobs should verify downloaded artifacts against a pinned checksum before building or testing

Scripts should fail hard on mismatch - a silent retry can hide a supply-chain problem

Keep the expected hashes in a signed, versioned manifest, not in a README

Verify images before writing to USB or SD cards, not after a failed boot

SHA-256 vs other algorithms

Use SHA-256 for all new integrity work. It is secure, universally supported, and recommended by NIST transition guidance.

SHA-1 is broken for collision resistance - researchers have demonstrated real collisions. Do not rely on SHA-1 for security.

MD5 is completely broken for security. It is fine as a fast non-security checksum for deduplication, but never for integrity against a motivated attacker.

SHA-512 offers a larger digest and is faster on 64-bit CPUs, but SHA-256 is the ecosystem standard - publishers list it, and tooling expects it.

What hashes cannot do

A hash proves a file has not changed since it was hashed. It does not prove who created it, when, or that the hash source was legitimate.

Proving authorship requires digital signatures - public-key cryptography over the hash, as in the signed-checksums workflow above.

And hashes do not provide confidentiality. Hashing a password produces a deterministic value that attackers can brute force; passwords need slow, salted KDFs such as Argon2id, scrypt, or bcrypt, never plain SHA-256.

Frequently Asked Questions

References

This article is based on industry standards and best practices from authoritative sources:

• NIST FIPS 180-4 - Secure Hash Standard (SHS): https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• NIST SP 800-131A Rev.2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths: https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
• RFC 6234 - US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF): https://www.rfc-editor.org/rfc/rfc6234
• OWASP Cryptographic Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html