MD5 vs SHA-256: What File Hashes Are For and How to Verify a Download

A hash function takes input of any size, whether a five-letter word or a five-gigabyte disk image, and boils it down to a fixed-length string. The same input always produces exactly the same digest. That determinism is the entire point: it lets two people who have never met agree on whether they are holding the identical file, without sending the file back and forth.

Two more properties make it useful. A hash is one-way, meaning that given a digest there is no practical way to reconstruct the original bytes. And it has the avalanche effect: flip one bit of the input and roughly half the output bits change, so there is no such thing as close. Watch what changing a single letter from lowercase to uppercase does to MD5.

The digest is really a string of bytes, almost always shown as hexadecimal, using the characters 0-9 and a-f. That is why the length alone tells you the algorithm: MD5 is 128 bits, which is 32 hex characters, and SHA-256 is 256 bits, which is 64 hex characters. Hand someone a 32-character checksum and it is MD5; 64 characters is SHA-256; 40 characters is the older SHA-1.

Both functions do the same job, mapping data to a fixed fingerprint. The difference that matters is whether that fingerprint holds up when someone is actively trying to cheat it. Here is the side-by-side.

Broken has a precise meaning here: MD5 fails collision resistance. A collision is two different inputs that produce the same digest. In 2004 Xiaoyun Wang and colleagues showed how to generate MD5 collisions on demand. What once needed a supercomputer now takes seconds on an ordinary laptop.

Why that is dangerous in the real world: if an attacker can craft two files with the same hash, they can get you or an automated system to approve a harmless-looking one, then later swap in the malicious twin, and the checksum still matches. This is not hypothetical. In 2008 researchers used MD5 collisions to forge a trusted certificate authority certificate. In 2012 the Flame espionage malware used an MD5 collision to fake a Microsoft code-signing signature and spread through Windows Update.

One nuance worth keeping straight. MD5's other guarantee, preimage resistance, meaning you cannot work backward from a digest to find an input that produces it, has held up far better and has no practical attack. But you do not get to lean on that when designing anything, because the moment an attacker can influence the input, collisions are back in play. Treat MD5 as unsafe for any security decision, full stop.

The word broken makes people want to purge MD5 from everywhere, but that misreads the threat. Collisions require an attacker deliberately crafting files. They say nothing about random, accidental change.

If a download drops some packets, a drive flips a bit through age, or a copy is truncated, the corrupted result is a random mutation. The chance that a random mutation lands on the same MD5 as the original is about 1 in 2 to the 128th power, a number with 39 digits. For catching accidents, MD5 is not just adequate, it is overkill, and it runs faster than SHA-256.

So there are legitimate places you will still see MD5:

SHA-256 is one member of SHA-2, a family NIST published in 2001. It produces a 256-bit digest, and after two decades of intense scrutiny it has no known practical collision or preimage attack. It is what secures the TLS certificates behind HTTPS, signs software packages, and anchors systems like Bitcoin and Git's newer object format.

Do not confuse it with SHA-1, the 160-bit predecessor. SHA-1 is also deprecated: in 2017 Google and CWI Amsterdam produced the first real SHA-1 collision, an attack they called SHAttered. If you have a choice, skip SHA-1 as well.

SHA-3, standardized in 2015, is not an upgrade you need to chase. It is built on a completely different internal design, called a sponge construction, to serve as a backup in case a weakness were ever found in SHA-2. For everyday file verification, SHA-256 is the safe, universal default.

The workflow is the same on every system. The publisher lists an official checksum next to the download. You compute the hash of the file you actually received. You compare the two strings. If they are identical, your copy matches what the publisher intended. If they differ by even one character, the file is corrupt or tampered, so delete it and download again.

Here are the commands. Note that on Windows, PowerShell's Get-FileHash defaults to SHA-256, so you can omit the algorithm for that one.

After running the command, compare the result to the published value. The comparison is case-insensitive, because hex is hex, so it does not matter if one side is uppercase. Eyeballing 64 characters is error-prone, so on Linux and macOS you can let the machine check for you: put the official value in a file and run sha256sum -c SHA256SUMS, which prints OK for each file that matches.

The caveat people miss most: a checksum is only as trustworthy as where you got it. If you download both the file and its checksum from the same server, and that server is compromised, the attacker simply publishes a matching hash for their malicious file, and you verify it happily. Get the checksum over HTTPS from the official site, ideally from a different location than the file mirror, and prefer a signed checksum when the project offers one.

Two mistakes are worth calling out because each one quietly defeats the whole exercise.

First, a matching hash proves integrity, not authenticity. It tells you the bytes match a given hash, not who produced that hash. Real supply-chain verification pairs a hash with a digital signature, using GPG, Sigstore, or operating-system code signing, where the publisher signs the checksum with a private key only they hold and you verify it with their public key. If you are installing something sensitive, look for the signature, not just the checksum.

Second, and extremely common: do not hash passwords with MD5 or SHA-256. Both are built to be fast, and fast is exactly wrong for passwords, because a modern GPU can try billions of SHA-256 guesses per second against a stolen database. Password storage needs a deliberately slow, salted algorithm such as bcrypt, scrypt, PBKDF2, or the current recommendation, Argon2. Salting alone does not save a fast hash; the slowness is the point. Hashing files and hashing passwords are different jobs with different tools.