MD5, SHA-1, SHA-256: Which Hash Should You Actually Use
Why MD5 and SHA-1 are still everywhere despite being broken, and a straightforward way to pick the right hash for what you're actually doing.
Published February 10, 2026
"Broken" gets thrown around loosely when people talk about MD5 and SHA-1, and it leads to some confused advice. Both are broken for one specific purpose: an attacker who wants to deliberately produce two different inputs with the same hash (a collision) can now do that for real money and real time, not theoretical decades. That doesn't mean either algorithm is useless everywhere; it means the question is what you're using the hash for.
What "broken" actually breaks
Collision resistance matters when the hash is standing in for trust: verifying a downloaded file wasn't tampered with, checking a digital signature, confirming two documents are identical when it matters that nobody could have swapped in a different one with the same hash. That's exactly the scenario MD5 and SHA-1 can no longer guarantee.
Collision resistance barely matters for checking whether a file got corrupted in transit, generating a quick fingerprint to spot duplicate files, or building a cache key. Nobody is engineering a malicious collision to sneak past your local dedupe script, so the practical risk in that context is close to zero even though the algorithm is technically "broken."
The one place MD5 and SHA-1 should never appear
Passwords. Neither MD5 nor SHA-1 was ever actually right for password storage, collisions or not, because both are fast to compute, which is exactly the wrong property for something an attacker will try to brute-force offline. A leaked MD5 password hash gets cracked in a rainbow table lookup, not a research paper. Use a purpose-built, deliberately slow password hash instead: bcrypt, scrypt, or Argon2. This isn't a nuance, it's the single most common real-world hashing mistake, and it has nothing to do with SHA-256 being "safer" than MD5, since SHA-256 is also too fast for password storage on its own.
A simple way to decide
For anything security-relevant, integrity checks on files you didn't create yourself, or new code being written today: use SHA-256 by default. It's fast, well-supported, has no known practical collision attack, and there's rarely a good reason to pick anything weaker for new work.
For legacy compatibility with a system that already expects MD5 or SHA-1 checksums, and where you're not defending against a deliberate attacker (matching an existing file manifest, a non-security dedupe key): it's fine to keep using them, since the property that's broken isn't the one you're relying on.
For passwords, always: bcrypt, scrypt, or Argon2, never a general-purpose hash function alone, no matter which one.
- SHA-256 or stronger: security-relevant checks, digital signatures, new development
- MD5 or SHA-1: fine for non-adversarial integrity checks and legacy compatibility, not fine for anything a motivated attacker could exploit
- bcrypt / scrypt / Argon2: passwords, always, regardless of which of the above you'd otherwise reach for