MD5 vs SHA-1 vs SHA-256: Which Hash Should You Use?

Pick a hash function and you'll find three camps online. One says MD5 is dead. Another says it's fine for everything that isn't security. A third insists you should only ever use the newest thing. Each camp has a point. The decision depends on what you're hashing and who might try to trick you.

The short answer

• New work that touches security: SHA-256 (or SHA-512).
• Checking a download or catching accidental corruption: SHA-256 if you can. MD5 or SHA-1 if that's all the publisher offers.
• Storing passwords: none of them. Use Argon2id, scrypt, or bcrypt.
• Cache keys, dedup, quick fingerprints for your own data: anything fast works, including MD5.

The four you'll run into

SHA-256 and SHA-512 both belong to the SHA-2 family. They work the same way and differ mainly in internal word size. On 64-bit hardware SHA-512 is often just as fast as SHA-256, sometimes faster, so the choice usually comes down to how long an output you want.

What 'broken' means here

When people say MD5 is broken, they mean collision resistance. A collision is two different inputs that produce the same hash. A good hash should make that practically impossible to do on purpose.

• MD5: researchers demonstrated practical collisions in 2004. By 2008 a team used MD5 collisions to build a rogue certificate authority certificate. Today you can generate MD5 collisions on an ordinary laptop.
• SHA-1: in 2017 Google and CWI Amsterdam published the first real SHA-1 collision (the SHAttered attack). Browsers and certificate authorities had already been phasing SHA-1 out.

That does not mean you can take an MD5 hash and recover the original file. That's a different property (preimage resistance), and MD5 is still mostly holding up there. The danger is someone crafting two files that look different to you and hash the same.

When MD5 or SHA-1 is still okay

If nobody is trying to trick you, a broken hash still does a fine job of catching random corruption. Common safe uses:

• Spotting duplicate files in your own photo folder.
• Building cache keys or ETags.
• Checking that a big copy or transfer finished without bit errors.
• Matching a legacy system that already stores MD5 values.

The line is simple. If an attacker gets to choose one of the inputs, don't use MD5 or SHA-1. If it's your own data and you just want a fingerprint, they're fine.

Why plain hashes are wrong for passwords

SHA-256 is secure for integrity checks, and passwords are secrets, so people often hash passwords with it. That mixes two jobs. SHA-256 is designed to be fast. A modern GPU can try billions of guesses per second against a leaked SHA-256 password hash, and people pick guessable passwords.

Password hashing needs to be deliberately slow and memory-hungry, with a unique random salt per user. That's what Argon2id, scrypt, and bcrypt are built for. OWASP's password storage cheat sheet lists Argon2id as the first choice. If you're building a login system, use your framework's built-in password hasher and don't roll your own.

What about HMAC?

If you need to prove a message came from someone who holds a secret key (webhook signatures are the classic case), you want HMAC-SHA-256, not a bare hash. A bare hash has no secret in it, so anyone can compute it. HMAC mixes a key in. The plain Hash Generator doesn't do keyed hashes, so use your language's crypto library for that.

See the avalanche effect yourself

Try this in the Hash Generator. Hash Hello World with SHA-256 and you get:

a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

Now change one letter to lowercase and hash hello world:

b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

One character of difference, and the two outputs share nothing you could use to tell they're related. Cryptographers call that the avalanche effect. It's why a hash works as a fingerprint. For MD5, Hello World gives b10a8db164e0754105b7a99be72e3fe5, half the length but the same behavior.

Our guide on checking a download with a checksum walks through the next step.