When you download an installer, a system image, or a dependency archive over the network, you are trusting a chain you cannot see: CDNs, mirrors, proxies, your local network. File checksums are how you stop trusting the chain and start trusting the bytes — and doing it right takes one minute.
What a hash actually guarantees
A cryptographic hash like SHA-256 maps any file to a fixed 256-bit fingerprint. Two properties make it useful for verification: the same bytes always produce the same fingerprint, and — as far as anyone can do — different bytes cannot be made to produce the same one. So when the publisher’s SHA-256 and your locally computed SHA-256 match, the file is bit-for-bit identical to what they signed off. A one-byte difference anywhere produces a completely different hash, which is why checksums catch corrupted downloads and tampered ones.
Why MD5 and SHA-1 are no longer good enough
MD5 collisions can be constructed in seconds on a laptop; SHA-1 collisions were demonstrated in 2017. For detecting a corrupted download (random bit flips), they still work fine. For detecting a deliberately tampered file, they are worthless — an attacker can craft a malicious file with the same MD5 as the legitimate one. Every serious software project has moved its published checksums to SHA-256; treat an MD5-only download page as a small yellow flag on its own.
The workflow, end to end
- Get the expected hash from an independent channel — the project’s HTTPS site, a signed release page, or a maintainers’ announcement. The same channel serving the file cannot vouch for it.
- Compute locally. Our File Hash tool computes SHA-256 (and SHA-1/MD5 for comparison) entirely in your browser — the file never leaves your machine, which matters precisely when you do not yet trust the file.
- Compare the full strings, not the first few characters. Case and
sha256:prefixes vary between tools; the hex values must match exactly. - Do this for everything in your supply chain that matters — installers, firmware, and the Docker images your production runs.
The habit most teams miss
Verifying the installer of an operating system is well-known; verifying the internal artifacts is where real supply-chain incidents actually land: that internal CLI fetched via curl | bash, the dependency bundle cached on a mirror, the backup archive restored after months. Hash everything you would not want silently swapped, publish the hashes where your team can find them, and re-verify on restore — a checksum recorded but never re-checked is decoration.
For files whose contents themselves need confidentiality — not just integrity — pair the workflow with encryption: hash after encrypting so the published checksum covers the exact artifact. The AES tool runs the encryption locally as well, keeping the whole verify-and-protect loop inside your browser.