Comparison
SHA-256 vs MD5: never use MD5 for security
One is dead for security. The other is the modern default. Don't mix them up.
By Buğra SözeriPublished
TL;DR.MD5 has been cryptographically broken since 2004 — collisions can be found in under an hour on a laptop — so never use it for security. SHA-256 has no known practical collision and is the modern default for TLS, JWT, Bitcoin, Git (new repos), and HMAC. Both are fine for non-adversarial checksums, but SHA-256 isn’t meaningfully slower on modern CPUs.
MD5 and SHA-256 are both cryptographic hash functions — they take input of any length and produce a fixed-length output (128 bits for MD5, 256 bits for SHA-256). Both are deterministic, both are fast, and they look superficially interchangeable. They aren’t. MD5 has been cryptographically broken since 2004. SHA-256 is fine.
The headline
| Property | MD5 | SHA-256 |
|---|---|---|
| Output size | 128 bits (32 hex chars) | 256 bits (64 hex chars) |
| Published | 1991 | 2001 (NIST FIPS 180-2) |
| Collision found | 2004 (Wang et al.) | Not yet (2026) |
| Chosen-prefix collisions | Practical since 2007 | None known |
| Used for TLS, JWT, crypto? | No | Yes |
Why MD5 is broken
A cryptographic hash function should make it computationally infeasible to find two different inputs that produce the same output (a “collision”). In 2004 Xiaoyun Wang and her team published a method to find MD5 collisions in roughly an hour on a personal computer.
It got worse. In 2007 a chosen-prefix collision attack emerged — given any two arbitrary file headers, an attacker could append carefully crafted bytes to make both files MD5-collide. This was used in 2008 to forge a rogue certificate authority signature using a $657 cluster of PlayStation 3s.
For security purposes, MD5 is dead. Anyone using MD5 for signature verification, content integrity, or password hashing is using broken cryptography.
Where MD5 is still acceptable
MD5 isn’t broken at all; it’s broken for cryptographic uses. Two categories where it’s still fine:
- Non-adversarial checksums.Verifying that a download wasn’t corrupted, or that a cache entry matches a key. There’s no attacker; you just need a fast, deterministic fingerprint. MD5 fits.
- Deduplication.Detecting that two files are identical, where forging a collision wouldn’t help any plausible attacker (storage system, build cache).
Even in these cases, SHA-256 is rarely meaningfully slower on modern hardware — Intel and AMD CPUs both have native SHA instructions. There’s no real reason to default to MD5 anymore.
Where SHA-256 is the right choice
- TLS handshakes and certificate signatures. SHA-256 is the modern standard.
- JWT signatures (HS256, RS256, ES256). The 256 refers to SHA-256.
- Bitcoin block hashes. Bitcoin uses SHA-256 twice in its proof-of-work.
- Git object hashes. Git is migrating from SHA-1 (which has also been broken) to SHA-256; new repositories should use SHA-256 from the start.
- HMAC-based message authentication. HMAC-SHA256 is the standard.
What about SHA-1?
SHA-1 (160 bits) sits between MD5 and SHA-256 on the timeline. Theoretical collisions were predicted in 2005; the first practical collision (SHAttered) was published in 2017 by Google. SHA-1 is deprecated for security uses, though Git still uses it (with extensive collision detection layered on top) until the SHA-256 migration completes.
What about MD5 for passwords?
Don’t. Don’t use SHA-256 directly either. Password hashing requires a slow, memory-hard function — bcrypt, scrypt, or argon2. Plain SHA-256 is too fast: an attacker with modern GPUs can compute ~10 billion SHA-256s per second, brute-forcing weak passwords in minutes. Slow hashing functions make this attack economically infeasible.
The pragmatic rule
If you’re hashing for any reason that touches security — authentication, signature verification, content integrity that an attacker might want to fool — use SHA-256 or stronger.
If you’re hashing for non-adversarial fingerprinting — deduplication, content-addressable storage where you control all the inputs — MD5 is technically fine, but SHA-256 isn’t slower on modern hardware, so default to it anyway. The cost of being wrong about which category you’re in is high; the cost of just using SHA-256 always is essentially zero.
Use our hash generatorfor either via Web Crypto — though notably we don’t ship MD5 in the UI, because the browser doesn’t provide it natively and we’d rather not encourage its use.
Numeric facts
- Output length: MD5 = 128 bits / 32 hex chars; SHA-256 = 256 bits / 64 hex chars — exactly 2× the bits.
- Collision resistance: MD5 ~2¹⁸ today (literally seconds on a laptop); SHA-256 ~2¹²⁸ — a 2¹¹⁰× ratio.
- Throughput on AMD Zen 4 with SHA-NI: MD5 ~700 MB/s; SHA-256 ~1.9 GB/s. With hardware acceleration SHA-256 is now ~2.5× faster than MD5 — the speed argument for MD5 inverted.
- Without acceleration: MD5 ~500 MB/s, SHA-256 ~250 MB/s — the historical 2× gap.
- Wang attack (2004): first practical MD5 collision found in ~1 hour on a single PC. Modern attacks (HashClash) find collisions in under 30 seconds on commodity GPUs.
- 2008 rogue CA exploit: Sotirov et al. forged a CA-signed certificate using 200 PlayStation 3 consoles (~$657 of compute) and an MD5 chosen-prefix collision.
- GPU brute-force rate (RTX 4090): ~50 billion MD5/s, ~9 billion SHA-256/s — both demolish unsalted password hashes in minutes.
- Argon2id default cost (OWASP 2024): 19 MiB memory, 2 iterations, 1 parallelism — ~50 ms per hash vs nanoseconds for raw SHA-256.
Decision matrix
| Use case | Hash |
|---|---|
| TLS certificate signing | SHA-256+ |
| JWT signature | SHA-256 (HS256/RS256/ES256) |
| Code / binary signing | SHA-256 |
| Bitcoin / blockchain proof-of-work | SHA-256 (double) |
| HMAC API request signing | HMAC-SHA-256 |
| S3 ETag (single-part upload) | MD5 — locked in by AWS contract |
Linux package md5sums file | MD5 — legacy, but new distros add SHA-256 |
| Internal deduplication, trusted inputs | Either; default SHA-256 on modern CPUs |
| Password hashing | argon2id / bcrypt / scrypt — neither raw |
Sources
- Wang, X. et al. — Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, CRYPTO 2004 — eprint.iacr.org/2004/199.
- Sotirov, A. et al. — MD5 considered harmful today: Creating a rogue CA certificate, 25C3 (2008) — win.tue.nl/hashclash/rogue-ca.
- NIST FIPS 180-4 — Secure Hash Standard (SHS) — csrc.nist.gov.
Frequently asked questions
- Is MD5 secure for password hashing?
- No, and even SHA-256 isn't the right choice for passwords. Both are too fast — an attacker with modern GPUs can compute ~10 billion SHA-256s per second, brute-forcing weak passwords in minutes. Use bcrypt, scrypt, or argon2; they're deliberately slow and memory-hard.
- When is MD5 still acceptable?
- Only for non-adversarial fingerprinting where no attacker benefits from a collision: file integrity checks on trusted downloads, cache key derivation, deduplication in a system you control end-to-end. Anywhere security depends on the hash, use SHA-256 or stronger.
- Is SHA-256 reversible?
- No — cryptographic hash functions are one-way by design. You cannot derive the input from the output. Lookup-based 'reversal' (rainbow tables) only works for inputs that have been hashed before, and salting defeats rainbow tables entirely.
- Why is MD5 still everywhere if it's broken?
- Backwards compatibility and inertia. The Content-MD5 header, Linux package managers, S3's ETag for non-multipart uploads, and countless internal tooling still emit MD5 because the cost of changing the protocol exceeds the cost of the residual risk. New systems should default to SHA-256.
Related
Published May 14, 2026