What SHA-256 Is, and How to Check a File Has Not Been Tampered With

Updated 2026-08-03 · 6 min read

A hash is a fixed-length fingerprint of data. Feed in a one-word message or a two-gigabyte file, and SHA-256 returns exactly 64 hexadecimal characters. That simple property turns out to be enormously useful.

The properties that make it work

Deterministic. The same input always produces the same hash, on any machine, forever.

Avalanche effect. Change one character and the output changes completely — not slightly, but entirely unrecognisably. This is why hashes are good at detecting tampering: there is no such thing as a "close" match.

One-way. You cannot reverse a hash to recover the original. Hashing is not encryption; there is no decryption step, by design.

Collision resistant. Finding two different inputs producing the same hash should be computationally infeasible. This is where older algorithms failed.

Why MD5 and SHA-1 are no longer trusted

Both were once standard and both are now broken for security purposes, because researchers demonstrated practical ways to construct two different files with the same hash. Once that is possible, a hash no longer proves a file is unmodified: an attacker could craft a malicious file matching the expected value.

They still appear for non-security purposes such as detecting accidental corruption, but for anything where someone might deliberately tamper, SHA-256 is the sensible minimum. It is worth noting that browsers deliberately do not offer MD5 at all in their built-in cryptography API.

Verifying a download

This is the everyday use. When a project publishes a checksum next to a download, they are giving you a way to confirm you received exactly what they published.

1. Download the file.
2. Compute its SHA-256 hash.
3. Compare against the published value.

Identical means the file is byte-for-byte what was published. Different means something changed — a corrupted download, an interrupted transfer, or in the worst case a modified file.

You do not need to compare all 64 characters by eye. Checking the first and last six is enough in practice, given that any change alters the whole string.

What a checksum does not prove

This distinction matters and is widely missed.

A checksum proves the file matches the value you compared it against. If an attacker controls the website, they can replace both the file and the published checksum, and the two will match perfectly.

So a checksum protects mainly against accidental corruption and against tampering in transit or on a mirror. Protection against a compromised source requires a digital signature, which uses a key the attacker does not hold. For most everyday downloads a checksum is a reasonable check; for anything security-critical, look for signatures.

Hashing and passwords

Hashes are also how well-built systems store passwords: the hash is stored, never the password itself, so a breach does not directly expose it.

Importantly, though, plain SHA-256 is the wrong tool here. It is designed to be fast, and speed helps an attacker guessing billions of candidates. Password storage uses deliberately slow algorithms such as bcrypt, scrypt, or Argon2, plus a random salt per password so identical passwords do not produce identical hashes.

Worth knowing if you ever build a system that stores credentials: reaching for SHA-256 alone is a well-known mistake.

Comparing text instead of files

A related everyday need is finding what changed between two versions of a document. A hash tells you whether something differs; a diff tells you what differs. The two answer different questions, and it is usually the second one you actually want when reviewing a change.