Next to almost every serious software download there is a long string of hex characters labelled SHA-256, and almost nobody checks it. That is partly because the instructions are rarely given, and partly because it is not obvious what checking it buys you.
It takes about thirty seconds, and it is worth understanding precisely what it does and does not prove.
What a checksum is
A cryptographic hash function takes input of any size and produces a fixed-length digest — for SHA-256, 256 bits written as 64 hexadecimal characters. Two properties make it useful here:
- Deterministic. The same file always produces the same digest, on any machine, forever.
- Collision resistant. Finding two different files with the same SHA-256 digest is computationally infeasible with any known technique.
Change a single bit anywhere in a 4GB installer and the digest changes completely — not slightly, but into an entirely unrelated value. That is the avalanche property, and it is what makes a digest a usable fingerprint.
What it protects you from
Realistically, two things:
Corruption
Downloads fail in ways that do not announce themselves. A connection drops and resumes badly, a proxy truncates a response, a disk writes a bad sector. The result is a file that looks complete and is subtly broken. Verifying the checksum catches this immediately, and it is the reason checksums existed long before anyone was worried about attackers.
A tampered mirror
If a project distributes through mirrors or a CDN, one of those could serve a modified binary. Comparing against a checksum published on the project's own site detects that substitution — provided the checksum itself came from a source the attacker did not control.
What it does not protect you from
This is the part usually left out, and it matters.
If an attacker can modify the file, they can very often modify the page displaying the checksum too. If both come from the same compromised server, they will match perfectly and tell you nothing. A checksum verifies integrity relative to a published value; it does not verify authenticity.
This is what cryptographic signatures are for. A GPG signature, or a platform code signature, proves the file was produced by someone holding a specific private key — something an attacker who has only compromised a web server cannot forge. When a project publishes both a checksum and a signature, the signature is the stronger check.
A checksum is still worth doing. It is fast, it catches the common cases, and it costs nothing. Just do not mistake it for proof of origin.
Checking it, on each platform
macOS and Linux
shasum -a 256 ~/Downloads/installer.dmg
On most Linux distributions sha256sum is also available and
behaves identically. If the project ships a SHA256SUMS file,
you can verify everything at once:
sha256sum -c SHA256SUMSWindows
PowerShell has it built in, with no installation required:
Get-FileHash .\installer.exe -Algorithm SHA256
The older Command Prompt equivalent is
certutil -hashfile installer.exe SHA256, which produces the
same value in a less readable format.
In a browser
This is the case where a web tool genuinely beats the alternatives, provided it runs locally. Uploading a 4GB installer to a website to learn its checksum is absurd, and on many corporate networks it is prohibited outright.
The hash generator on this site reads the file with the File API and hashes it in memory using the Web Crypto API. Nothing is uploaded. Drop the file on the page, paste the published checksum into the verify field, and the comparison is done for you — case-insensitively, which matters because published checksums are inconsistently cased and comparing 64 hex characters by eye is exactly how mismatches get missed.
Comparing by eye is the weak link
If you take one practical thing from this: do not scan two hex strings visually and conclude they match. Human pattern matching is very good at seeing what it expects. People check the first six characters, check the last six, and declare victory — which is precisely the check an attacker optimises against, since producing a file whose digest shares a short prefix is far cheaper than a full collision.
Paste both values into something that compares them completely. Any of the
commands above with a -c flag will do it, and so will a tool
that does the comparison for you.
Which algorithm
- SHA-256 — the default, and the right answer for essentially everything today.
- SHA-512 — equally sound, and marginally faster on 64-bit hardware. Fine if that is what was published.
- SHA-1 — broken for collision resistance since 2017, when a practical collision was demonstrated. Still adequate as a corruption check, unacceptable as a security control.
- MD5 — thoroughly broken. Colliding files can be generated on a laptop in seconds. If a project publishes only an MD5, treat it as a corruption check and nothing more.
You do not choose the algorithm — the publisher does. Your job is to use whichever they published, and to know how much confidence it earns.
A note on hashing and passwords
Because it comes up constantly: none of this applies to storing passwords. SHA-256 is designed to be fast, which is exactly right for checksumming a file and exactly wrong for a password, because the attacker gets that same speed against a leaked table.
Password storage needs a deliberately slow, salted key-derivation function — Argon2id, scrypt or bcrypt — tuned so a single verification takes a noticeable fraction of a second. That is invisible to your user and ruinous to someone working through millions of guesses. A salted SHA-256 is still the wrong tool: the salt defeats precomputed rainbow tables and does nothing about raw speed.