MD5 vs SHA-256: Which to Use and When

Use SHA-256 whenever a hash needs to be trustworthy, and treat MD5 as a fast checksum for accidental corruption only, never for security. The two functions look similar because both take any input and return a fixed-length fingerprint, but they are not interchangeable. MD5 has been broken for security purposes for years, while SHA-256 remains sound. The trick is knowing which jobs actually need security guarantees and which do not, because the answer decides whether MD5 is a reasonable convenience or a dangerous mistake.

What is the core difference between MD5 and SHA-256?

The headline difference is digest length and cryptographic strength. MD5 produces a 128-bit digest, written as 32 hexadecimal characters. SHA-256, part of the SHA-2 family, produces a 256-bit digest, written as 64 hexadecimal characters. Both are deterministic, meaning the same input always yields the same output, and both are one-way in intent: you cannot read the original input back out of the hash.

Digest length matters because a longer output space makes brute-force and accidental collisions astronomically less likely. But length alone is not the whole story. What truly separates these functions is whether the mathematical properties a hash promises still hold, and for MD5 they do not.

Why is MD5 considered broken?

MD5 is broken because attackers can deliberately construct collisions. A cryptographic hash is supposed to be collision-resistant: it should be infeasible to find two different inputs that produce the same digest. For MD5, that resistance has collapsed. Researchers demonstrated practical collision attacks long ago, and today generating two distinct files with an identical MD5 hash is fast and cheap on ordinary hardware.

That single failure poisons every security use. Consider why: if you sign a document by signing its MD5 hash, an attacker who can craft a colliding file gets a valid signature on a file you never approved. If you distribute software and publish its MD5 to prove authenticity, an attacker can prepare a benign file and a malicious file with the same hash, get you to vouch for the benign one, and swap in the malicious one. The hash no longer identifies a unique input, so it can no longer prove anything about which input you have.

SHA-1 is in the same category. It produces a 160-bit digest, but a practical collision has been publicly demonstrated, so it is unsafe for signatures, certificates, or tamper detection. For any adversarial setting, both MD5 and SHA-1 should be considered off the table.

When is MD5 actually fine to use?

MD5 is fine when there is no adversary, only accident. The attacks against MD5 require someone deliberately crafting inputs. If your only concern is whether a file got corrupted in transit or on disk, no one is crafting anything, and MD5’s speed can be a genuine convenience.

Reasonable non-security uses include:

• Detecting accidental corruption of a download or backup where the source is trusted and the risk is bit rot, not tampering.
• Deduplication, where you want a fast way to notice that two files are probably identical.
• Non-cryptographic cache keys or shard keys, where a collision is a minor inefficiency rather than a security event.

The rule of thumb: if a collision would only cost you a little performance or a rare false match, MD5 is acceptable. If a collision would let someone deceive you, it is not. The moment an attacker benefits from making two inputs hash the same, you have left MD5’s safe zone.

When should you reach for SHA-256?

Reach for SHA-256 whenever the hash is a security claim. That covers verifying that a downloaded file matches what the publisher intended, checking that data has not been altered, building HMAC message authentication codes, content-addressed storage where the hash is an identity, and as the underlying hash in digital signatures. In all of these, you are relying on the promise that a matching hash means matching content, and SHA-256 still keeps that promise.

A concrete integrity workflow looks like this. A publisher computes the SHA-256 of a release and posts the digest. You download the file, compute its SHA-256 locally, and compare.

# Compute a SHA-256 digest of a file
$ sha256sum installer.bin
9f2c...c1a4  installer.bin

# Compare against the published digest; a match means
# the file is byte-for-byte what the publisher released.

Because no practical collision or preimage attack against SHA-256 is known, an attacker cannot feasibly produce a different file with the same digest, so a match is meaningful evidence of integrity. If you need a hash for anything where being deceived would matter, SHA-256 (or another SHA-2 or SHA-3 function) is the baseline.

You can generate MD5, SHA-1, and SHA-256 digests of text right in your browser with our hash generator, which is handy for eyeballing the length difference and for quick integrity checks without installing anything. Like the rest of the site, it runs client-side, so the text you hash stays on your machine rather than being sent to a server.

Why is neither MD5 nor SHA-256 right for passwords?

Neither belongs anywhere near password storage, and this is the most common and most damaging misuse. The reason is speed. MD5 and SHA-256 are engineered to be fast, so they can hash large volumes of data quickly. That is a virtue for checksums and a catastrophe for passwords, because the same speed lets an attacker who steals your database try enormous numbers of password guesses per second against the stolen hashes.

Passwords are low-entropy and often reused, so an attacker with a fast hash and a wordlist can recover a large fraction of them cheaply. Adding a plain SHA-256 does not help much; it is still fast. The answer is a purpose-built password hashing function that is deliberately slow and memory-hard, combined with a unique random salt per user so that identical passwords produce different stored values and precomputed tables are useless.

The appropriate algorithms are bcrypt, scrypt, and Argon2. Each is tunable so you can raise the cost as hardware improves, keeping each guess expensive for an attacker while remaining acceptable for a single legitimate login. If you are storing passwords, use one of these, never a bare general-purpose hash. We cover the full reasoning, including salting and slow key derivation functions, in a companion article on how password hashing actually works.

What is the quick decision rule?

Match the tool to the threat. Ask what a collision or a fast attacker would cost you, and choose accordingly.

• Guarding against accidental corruption, no attacker: MD5 is acceptable, though SHA-256 is a fine default too.
• Proving a file or message was not tampered with: SHA-256, never MD5 or SHA-1.
• Signatures, certificates, HMAC, content addressing: SHA-256 or another SHA-2 or SHA-3 function.
• Storing passwords: none of the above; use bcrypt, scrypt, or Argon2 with a per-user salt.

Held together, the guidance is simple. MD5’s speed is its only remaining virtue, useful only where no one is trying to fool you. SHA-256 is the workhorse for integrity and the sensible default when you are unsure. And for the specific job of protecting passwords, reach past both to a slow, salted key derivation function built for exactly that purpose.