SHA-256 vs MD5: never use MD5 for security

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

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.