MD5 vs SHA-256 vs Bcrypt: Choosing the Right Hash

MD5, SHA-1, SHA-256, and bcrypt all take input and produce a fixed-length digest, which tempts people into treating them as interchangeable. They aren't. Two of them are broken for security work, one is the modern workhorse for integrity, and one exists for a single job the other three are dangerously bad at. Picking between them isn't a matter of taste — each question about your use case has a definite answer.

Here's the comparison most posts on this topic won't make cleanly: "broken" means something specific, it doesn't mean what most people assume, and knowing exactly what broke tells you exactly when each algorithm is still acceptable. Let's be precise.

The four algorithms on one table

What "broken" actually means (and doesn't)

A cryptographic hash makes three promises: you can't reverse a digest back to its input (preimage resistance), you can't find a second input matching a given digest (second-preimage resistance), and you can't manufacture any two inputs that collide (collision resistance).

MD5 and SHA-1 broke the third promise. Researchers demonstrated manufactured MD5 collisions in 2004, and the SHAttered attack did the same to SHA-1 in 2017 — two different PDFs, one SHA-1 digest. Notably, the first two promises still stand for both: nobody can take your MD5 digest and recover the input from the mathematics alone.

So is MD5 fine after all? No.

Collision attacks are how forged certificates and tampered documents happen — an attacker crafts two versions of a file, gets the innocent one signed, and swaps in the malicious twin with the same digest. And the line between "collision doesn't matter here" and "suddenly it does" has a habit of moving as systems evolve. The engineering rule that survives contact with reality: retire broken primitives everywhere, because contexts blur.

The steelman for MD5's survival is narrow but real: as a fast fingerprint in non-adversarial settings — cache keys, deduplication, change detection in your own pipeline — no attacker is involved, and MD5's speed is a genuine advantage. That's a defensible engineering call, as long as everyone maintaining the system knows the boundary.

SHA-256: the default, and why it isn't the answer to everything

SHA-256 keeps all three promises with no practical attacks after two decades of analysis. It's the standard for file checksums and digital signatures, it's what certificate chains and blockchains lean on, and if a task says "verify this data is intact," SHA-256 is the answer. Generate one in your browser with the SHA256 Generator and compare digests with the Hash Compare tool.

Which makes the next fact feel wrong: SHA-256 is a poor choice for storing passwords. Not because of any flaw — because of its chief virtue. It's fast, and against a leaked password database, fast works for the attacker: commodity GPUs try billions of candidate passwords per second against fast hashes. Salting helps against precomputed tables but does nothing about raw guessing speed. The defense isn't a stronger fast hash. It's abandoning speed on purpose.

Bcrypt: slow on purpose, for exactly one job

Bcrypt is the deliberate inversion: an algorithm engineered to be expensive per computation, with a cost factor that doubles the work each time you raise it by one, and automatic per-password salting baked into its output format. At a well-tuned cost, an attacker's guess rate collapses from billions per second to thousands — the difference between cracking a leaked database over a weekend and over a geological era.

The trade-off is the point: your server pays a quarter-second once per login; the attacker pays it for every single guess. How to tune that cost properly is its own topic — our bcrypt guide covers picking a cost factor as a measured time budget — and you can feel the slowdown yourself in the Bcrypt Hash Generator.

One symmetry worth noticing: using bcrypt for file checksums would be as wrong as SHA-256 for passwords. Nobody wants a build pipeline that spends 250 ms per artifact on purpose. Wrong tool, opposite direction.

The decision framework

Ask what the hash is for, and the choice makes itself:

1. Verifying data integrity — downloads, backups, signatures, dedupe with any adversarial exposure → SHA-256.
2. Storing passwords — anything a human typed as a credential → bcrypt (or Argon2id in new designs).
3. Authenticating messages with a shared secret — webhooks, API signing → HMAC-SHA256 via the HMAC Generator, which adds a key so only holders can produce valid digests.
4. Interoperating with a legacy system that demands MD5 or SHA-1 — comply at the boundary, and treat those digests as identifiers, not security.

It depends on the job — and now you know precisely what it depends on.

Conclusion

MD5 and SHA-1 lost the collision promise, so they're retired from security and tolerable only as non-adversarial fingerprints. SHA-256 keeps every promise and owns the integrity jobs. Bcrypt gives away the one thing the others compete on — speed — because slowness is the entire defense passwords need. Match the algorithm to the promise your system actually requires, and the "versus" in MD5 vs SHA-256 vs bcrypt mostly dissolves: they were never competing for the same job in the first place.