SHA-256 vs MD5 vs Bcrypt

Understanding when to use each hashing algorithm

Quick Answer

  • Passwords? → Use bcrypt (or Argon2). Never MD5 or SHA-256.
  • File checksums? → Use SHA-256. Fast and collision-resistant.
  • Legacy system compatibility?MD5 for non-security checksums only.

Comparison Table

PropertyMD5SHA-256Bcrypt
Output length128 bits (32 hex)256 bits (64 hex)60 chars
Speed (per sec)~10 billion~5 billion~1,000
Collision-resistantNo (broken)YesYes
Built-in saltNoNoYes (128-bit)
Adjustable costNoNoYes (2^cost)
Password hashingNeverNoYes (designed for it)
File integrityLegacy onlyRecommendedNo
Year introduced199220011999

MD5 — Fast but Broken

MD5 produces a 128-bit hash and was designed in 1992 by Ronald Rivest. It was the standard for checksums and password hashing for over a decade. However, MD5 has been cryptographically broken since 2004 — researchers can generate collisions (two different inputs with the same hash) in seconds.

Still acceptable for: Non-security checksums (verifying file downloads), cache keys, deduplication, partitioning. Never use for: Password hashing, digital signatures, certificate verification, or any security-sensitive application.

SHA-256 — Secure and Fast

SHA-256 is part of the SHA-2 family designed by the NSA and published by NIST in 2001. It produces a 256-bit hash and is collision-resistant — no practical collision has ever been found. It's the backbone of Bitcoin mining, TLS certificates, Git commit hashes, and code signing.

Why not for passwords? SHA-256 is designed to be fast — a modern GPU can compute ~5 billion SHA-256 hashes per second. An attacker can brute-force an 8-character password in minutes. Speed is a feature for file verification but a vulnerability for passwords.

Bcrypt — Built for Passwords

Bcrypt is specifically designed for password hashing. Its key features:

  • Intentionally slow — ~1,000 hashes/sec vs billions for SHA-256. Makes brute-force impractical.
  • Built-in salt — each hash includes a random 128-bit salt, preventing rainbow table attacks.
  • Adjustable cost factor — increase the cost as hardware improves. Cost 10 today, cost 14 in five years.
  • Self-contained output — the hash string includes algorithm version, cost, salt, and hash. No separate salt storage needed.
$2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
 ─┬─ ─┬─ ─────────────┬──────────── ──────────┬───────────────
  │   │               │                        │
  │   │               └── 22-char salt          └── 31-char hash
  │   └── cost factor (2^10 = 1024 iterations)
  └── algorithm version (2b = current)

What About Argon2?

Argon2 won the 2015 Password Hashing Competition and is technically the most secure option. It adds memory-hardness — attackers need large amounts of RAM, making GPU and ASIC attacks much more expensive. Argon2id (the recommended variant) combines GPU-resistance and side-channel resistance.

In practice, bcrypt remains the most widely deployed and battle-tested option. OWASP recommends both bcrypt and Argon2id. If your framework supports Argon2id (like PHP 7.2+, Python passlib, Go), use it. Otherwise, bcrypt with cost 12+ is excellent.

Decision Flowchart

Are you hashing passwords?

→ Yes: Use bcrypt (cost 12+) or Argon2id

→ No: Continue ↓

Do you need collision resistance?

→ Yes: Use SHA-256 (or SHA-3 for future-proofing)

→ No: Continue ↓

Non-security checksum? (cache keys, dedup)

MD5 is fine, or use xxHash/CRC32 for even more speed

Hash Generator Tools