What Is a Checksum? Verifying Downloads With SHA-256

A checksum is a short, fixed-length value computed from a file's bytes so that any change to those bytes produces a different value. To verify a download, you recompute the checksum locally and compare it with the value the publisher printed. A SHA-256 checksum is 64 hexadecimal characters long. If even one bit differs, roughly half of those characters change.

As of 2026, SHA-256 is the default checksum algorithm for verifying software downloads. It produces a 256-bit digest, and no practical collision has ever been published. MD5, by contrast, has had practical collisions since 2004, and they can now be generated in seconds on a laptop.

How a SHA-256 checksum verifies a download

The publisher hashes the finished installer once, at release time, and publishes the resulting digest. You download the file, run the same hash function over every byte you received, and compare the two strings. A match means your copy is bit-for-bit identical to the file the publisher hashed. A mismatch means something changed between their build server and your disk.

The mechanics are deterministic and stateless. SHA-256 processes the file in 512-bit blocks through 64 compression rounds and carries a 256-bit internal state forward from block to block. That design has three practical consequences:

• Cost scales linearly with file size. On a modern CPU with SHA extensions, hashing typically runs at 1 to 2 GB/s per core (an estimate; results vary by hardware), so a 4 GB ISO verifies in a few seconds.
• The hash cannot be resumed from the middle. If a file is altered after download, the whole file has to be re-hashed.
• The digest says nothing about where the file came from. It only shows whether your copy matches whatever was hashed.

That last point is the one most glossaries leave out. A checksum proves file integrity. It proves authenticity only when the expected value reaches you through a channel the attacker cannot also modify.

Where file integrity checks sit in the delivery stack

Every layer between the build server and the user's disk already runs some form of integrity check, but none of them covers the full path. TCP uses a 16-bit ones'-complement checksum, which is too weak to catch every corrupted segment at internet scale. TLS 1.3 adds AEAD authentication tags, which reliably detect tampering in transit, but only between two connection endpoints.

TLS cannot see a bad block on the origin's disk, a truncated object cached at an edge node, a partially written file on the user's machine, or a mirror operator who replaces the binary. An end-to-end checksum is the only check that spans the entire path from build artifact to installed file.

The same idea shows up inside infrastructure. Object stores can validate CRC32C or SHA-256 values on upload. RFC 9530 defines the Content-Digest HTTP header for carrying a hash of the response body. Package managers pin SHA-256 hashes in lockfiles. For software publishers who deliver installers through a CDN, a published digest is how users can confirm that the cached copy matches the release. Delivery platforms such as BlazingCDN's CDN for software companies and installer delivery serve objects up to 50 GB, which is exactly the size range where a silent truncation is easy to miss without a hash.

Checksum vs. neighboring concepts

SHA-256 vs. MD5: Both detect accidental corruption equally well. MD5's 128-bit digest has been cryptographically broken for two decades, though: an attacker can craft two different files with the same MD5. SHA-256 resists that attack. An MD5 checksum is acceptable for spotting a flaky download and unacceptable as evidence that a binary is genuine.

Checksum vs. CRC: A cyclic redundancy check such as CRC32 is designed to catch burst errors in storage and transmission, and it is very cheap to compute. It is not a cryptographic function. Anyone can modify a file and adjust a few bytes to keep its CRC unchanged.

Checksum vs. digital signature: A signature, such as a GPG signature on a checksum file or an Authenticode signature on a Windows installer, binds the digest to a private key that only the publisher holds. A checksum answers "is this the same file?" A signature answers "did this publisher release this file?"

Which mechanism catches which failure

An unsigned checksum hosted next to the file stops accidents but not attackers, so the hash and the binary must travel by different trust paths.

How to verify a checksum on Linux, macOS and Windows

To verify a checksum, compute the SHA-256 digest of the downloaded file with your operating system's built-in tool, then compare it character for character with the publisher's value. Every major OS ships a tool for this, so nothing needs to be installed. The comparison is exact: there is no "close enough."

1. Linux: run sha256sum followed by the file name. If the publisher provides a SHA256SUMS file, pass it to sha256sum with the -c option. The tool prints OK or FAILED for each listed file.
2. macOS: run shasum with the algorithm option set to 256, followed by the file name.
3. Windows: in PowerShell, run Get-FileHash with the Algorithm parameter set to SHA256. The output is uppercase hex. Comparison is case-insensitive, so this does not matter.

A standard SHA256SUMS file holds one line per artifact: the 64-character digest, two spaces, then the file name. Well-run projects also publish a detached GPG signature for that file. The correct order is to verify the signature on SHA256SUMS first, then check the installer against SHA256SUMS. Reversing that order trusts an unauthenticated list.

Common misconceptions about the sha256 checksum

"HTTPS makes checksums redundant." HTTPS protects the connection, not the object. Corruption at rest, a bad cache fill or a tampered mirror all arrive over a perfectly valid TLS session.

"A matching hash proves the file is safe." It proves the file matches what the publisher hashed. If the build pipeline itself was compromised, the malicious binary will carry a matching, correctly published hash.

"MD5 is fine because collisions need special conditions." Chosen-prefix MD5 collisions are practical. For files an adversary can influence, MD5 gives no meaningful assurance. Publishers should list SHA-256 and treat MD5 as legacy at most.

"Collisions happen by accident." For SHA-256 they effectively do not. The generic collision bound is about 2^128 operations, so an accidental collision is far less likely than undetected memory or disk errors on the machine doing the check.

FAQ: Checksum and SHA-256 download verification

What does it mean when a SHA-256 checksum does not match?

A mismatched SHA-256 checksum means your file differs from the one the publisher hashed. The usual causes are an interrupted download, a stale or corrupted cached copy, or a wrong version. Re-download the file, ideally from the primary source. If the mismatch persists, treat the file as untrusted and do not run it.

Is MD5 still good enough to verify a checksum?

MD5 is good enough only for detecting accidental corruption, such as a truncated transfer. It is not acceptable for proving authenticity, because attackers can produce different files with identical MD5 digests. When a publisher lists both MD5 and SHA-256, always compare the SHA-256 value, and preferably check a signed checksum file as well.

Does a checksum protect file integrity against attackers?

A checksum protects file integrity against attackers only when the expected hash reaches you through a channel they cannot modify. If the hash sits on the same compromised server as the file, both can be replaced together. A GPG-signed checksum file, or a code signature on the installer, closes that gap.

How long does it take to compute a SHA-256 checksum on a large file?

Computing a SHA-256 checksum typically takes a few seconds per gigabyte or less on current hardware. CPUs with SHA instruction extensions commonly reach 1 to 2 GB/s per core (an estimate). Disk read speed often becomes the bottleneck for multi-gigabyte installers, game builds and disk images stored on slower drives.

Add checksum verification to your release pipeline

This week, pick your three largest release artifacts and audit them. Is a SHA-256 digest generated in CI from the exact bytes you upload? Is the SHA256SUMS file signed? Is the hash served from a different origin than the binary? Then download each artifact through your CDN from two regions and compare the digests against the build output. A mismatch there points to a cache or origin problem that users are already hitting.

If you distribute installers, patches or disk images at volume, BlazingCDN's Files on Demand delivery for large software files serves objects up to 50 GB and offers a 14-day testing period on real production traffic, which is enough time to run this verification test against your own releases.