How checksums verify downloads and backups — and which one to use
Download a large file and the site shows a string like sha256: 9f86d0…. Compute the same function over the file you received and compare: if the strings match, every byte arrived intact. That is a checksum, and the idea — a short fingerprint of a large thing — runs through backups, git, package managers and forensics. The MD5/CRC32 tool and the hash generator compute them in your browser; here is what they mean.
What a checksum is
A checksum is a fixed-size value computed from all the bytes of a file such that any change to the input — one bit flipped — almost certainly changes the output. The simplest (adding the bytes up) catches many errors but misses others, such as two bytes swapped; the good ones are hash functions designed so that changes anywhere scramble the whole result (the avalanche effect). Two files with the same checksum are, for practical purposes, the same file; a mismatch means they differ somewhere. Hashing, encryption and encoding covers the broader family.
CRC32, MD5, SHA-256
- CRC32 — a 32-bit cyclic redundancy check, designed for detecting transmission errors (it provably catches all single-bit and most burst errors). Fast, tiny, used inside ZIP files, Ethernet frames and PNG chunks. Not resistant to deliberate tampering: forging a file with a chosen CRC is trivial.
- MD5 — a 128-bit cryptographic hash from 1992, now broken for security: researchers can construct two different files with the same MD5. Still fine for detecting accidental corruption and widely shown alongside downloads for that reason, but useless against an attacker.
- SHA-256 — 256 bits, from the SHA-2 family (2001), no practical collisions known. The current default for verifying downloads, in git (recent versions), package signatures and certificates. SHA-1 sits between: broken for collisions since 2017, still in older systems.
Verifying a download
- Find the published checksum on the download page (or a file named SHA256SUMS).
- Compute the checksum of the file you received — the browser tool reads it locally, or on a command line:
sha256sum file(Linux),shasum -a 256 file(macOS),certutil -hashfile file SHA256(Windows). - Compare every character. A match means the bytes are identical to what the publisher hashed.
The step people skip: the checksum must come from somewhere the attacker can't edit. If the download and the checksum sit on the same compromised mirror, both are wrong together. That's what signatures are for.
Other things checksums do
Git names every commit and file by its hash, so history can't be altered silently. Backup tools compare checksums to find changed files and to detect bit rot on old drives. Package managers verify every download before installing. Deduplication systems store one copy of identical blocks. Forensic examiners hash evidence at seizure so any later change is detectable. And the duplicate finder uses per-page hashes to spot repeated pages. In each case the property used is the same: same bytes, same hash; different bytes, different hash.
What a checksum is not
It is not a signature: anyone can compute a checksum of anything, so a checksum proves integrity (unchanged) but not origin (who made it). A digital signature (Electronic vs digital signatures: what each is, and what a drawn signature on a PDF proves) signs the hash with a private key, proving both. It is not encryption: the file is unchanged and readable. And it is not a password store on its own: hashing a password with SHA-256 is fast enough to brute-force; password storage needs slow, salted functions (bcrypt, Argon2), which How long should a password be? touches on.
Sources and further reading
The claims in this guide rest on these references, which were checked when the guide was last updated. Spotted an error? The contact page says how to report it.