Checksums and File Integrity: Verifying Downloads with SHA-256

You download an installer, a release tarball, or a firmware image, and the project helpfully publishes a long hexadecimal string next to it labeled "SHA-256." That string is a checksum, and comparing it against the file you received is one of the cheapest security habits there is — especially now that supply-chain tampering is a real, ongoing threat. Here is what a checksum actually proves, and how to use one.

What a checksum is

A checksum is the output of a hash function run over the file's bytes. Change a single bit anywhere in the file and the hash changes completely and unpredictably. So if the hash you compute over your downloaded copy matches the hash the project published, you have strong evidence the file is byte-for-byte identical to what they released — no corruption in transit, no tampering along the way.

To check one, run the file's contents through a SHA-256 hash and compare. The Hash Generator computes SHA-256 (and others) in your browser, so you can verify small files without installing anything. On the command line, sha256sum file (Linux), shasum -a 256 file (macOS), or Get-FileHash file (Windows PowerShell) do the same.

Why SHA-256, not MD5

Older projects still publish MD5 or SHA-1 checksums, and for catching accidental corruption those are fine. For security, they are not: both MD5 and SHA-1 are broken against collision attacks, meaning a motivated attacker can craft two different files with the same hash. If the checksum is meant to protect against tampering, it needs to be SHA-256 (or SHA-512). If a project only offers an MD5, treat it as a corruption check, not a tamper-proof guarantee. When you come across a bare hash and are not sure which algorithm produced it, the Hash Identifier narrows it down by length and format.

The part checksums do NOT solve

A checksum only proves the file matches the published hash. It says nothing about whether the publisher is trustworthy or whether the hash itself was tampered with. If an attacker can replace both the download and the checksum on the same page, matching them proves nothing. That is why the strongest verification pairs a checksum with a cryptographic signature (GPG, Sigstore), where the hash is signed by a key you trust independently. Think of it this way:

• Checksum match → the file is intact and identical to the published one.
• Valid signature → the published hash genuinely came from the project, not an impostor.

For everyday downloads a matching SHA-256 is a solid baseline; for anything security-critical, look for a signature too. This is the same integrity mindset behind defending against dependency tampering, covered in the 2026 npm supply-chain post.

A practical verification flow

1. Note the published SHA-256 next to the download.
2. Compute the hash of your copy — with the Hash Generator for small files, or sha256sum / Get-FileHash for large ones.
3. Compare the two strings. They must match exactly; a single different character means a different file.
4. For high-stakes downloads, verify the project's signature over the checksum as well.

The underlying idea — a fixed-size fingerprint of arbitrary data — is the same one behind password storage and message authentication; the Hashing Guide and Hash Algorithms Compared go deeper on where each algorithm fits.

The takeaway

Verifying a download's SHA-256 takes ten seconds and catches both corruption and a whole class of tampering. Use SHA-256 rather than MD5 for anything security-related, remember that a checksum proves integrity but not authenticity, and reach for the Hash Generator whenever a project hands you a hash to check.