SHA-256 vs MD5: Which Hash Should You Actually Use in 2026?
MD5 turns 34 this year, and it's been cryptographically broken since 2004. SHA-256 is the sensible default for almost everything you're building today. But "broken" doesn't mean "never use" — there are still narrow cases where MD5 is fine, and cases where even SHA-256 is the wrong choice (spoiler: passwords). This guide walks through the differences and gives you a clear pick per use case.
The 30-second answer
- File integrity, signatures, blockchain, API auth: SHA-256.
- Passwords: neither — use bcrypt, scrypt, or Argon2.
- Non-security fingerprints (cache keys, dedup, ETags, git blob hashes internally): MD5 is fine and faster.
- Anything a user or attacker could tamper with: SHA-256.
Why MD5 is broken
MD5 produces a 128-bit digest. In 2004, researchers demonstrated collisions — two different inputs producing the same MD5 hash. By 2008, attackers forged a fake SSL certificate using MD5 collisions. Today you can generate a colliding pair of PDFs on a laptop in under a minute.
What that means practically: if MD5 is what stands between an attacker and a trust decision, you're one weekend of compute away from a bypass. Signatures, code integrity, TLS — anywhere an attacker chooses the input, MD5 fails.
Why SHA-256 is safe (for now)
SHA-256 is part of the SHA-2 family, standardized by NIST in 2001. It produces a 256-bit digest, and after 24 years of public scrutiny no practical collision or preimage attack exists. The 2017 SHAttered attack broke SHA-1 but not SHA-256 — the two are structurally similar but SHA-256's larger state size makes the same attack computationally infeasible.
For most developers, SHA-256 is the "no one will second-guess this" choice for the next decade. SHA-3 (a completely different construction) exists as a backup should SHA-2 ever fall.
Speed comparison — MD5 is roughly 30% faster
On a modern CPU, hashing 1 GB takes about 2 seconds with MD5 versus 2.6 seconds with SHA-256. That's meaningful for high-throughput non-security workloads (deduplication pipelines, CDN cache keys) and irrelevant for the once-per-request auth signature.
Why passwords need their own thing
Passwords are the one place where fast hashing is bad. An attacker who steals a leaked database wants to guess billions of passwords per second — both MD5 and SHA-256 let them do exactly that on a GPU.
Password hashing functions like bcrypt, scrypt, and Argon2 are deliberately slow and memory-hard. A single hash takes ~100 ms and hundreds of MB of RAM, so a brute-force attempt that would finish overnight against SHA-256 takes centuries against Argon2.
Rule: never store passwords as raw MD5, SHA-1, or SHA-256. Even salted.
When MD5 is still fine
MD5 remains useful in scenarios where collisions don't matter because no attacker controls the input:
- Cache keys and ETags — if two files collide, worst case is a cache miss.
- Deduplication — combine with a byte-level compare on collision.
- Git internally uses SHA-1 (moving to SHA-256), which is stronger than MD5 but still not for security-critical decisions.
- Non-security fingerprints in analytics or logging.
Try it yourself
Paste any text or drop a file into the Hash Generator and compare MD5, SHA-1, SHA-256, SHA-384, SHA-512, and CRC32 side by side. Everything runs in your browser — nothing is uploaded.
Related reading
Keep reading
How to Format JSON in JavaScript (2026 Guide)
Learn every practical way to format, pretty-print, indent, and validate JSON in JavaScript — with copy-paste examples for Node.js and the browser.
Base64 Encoding Explained: What It Is and When to Use It
Base64 in one plain-English guide: how it works, when to use it, when NOT to, and how to encode and decode it in every major language.