MD5 vs SHA-256 vs bcrypt: Which Hash Should You Use?
Hashing takes any input and produces a fixed-length "fingerprint" that's practically impossible to reverse. It's everywhere — file integrity checks, digital signatures, blockchains, and password storage. But MD5, SHA-256, and bcrypt are built for very different jobs, and using the wrong one (especially for passwords) is a serious, common security mistake. Here's how to choose correctly.
First, what a good hash function guarantees
A cryptographic hash should be deterministic (same input, same output), fast to compute for legitimate use, and resistant to two attacks: finding the original input from the hash (preimage resistance), and finding two inputs with the same hash (collision resistance). When a hash function "breaks", it usually means researchers found a practical way to create collisions.
MD5: fast fingerprints only
MD5 produces a 32-character (128-bit) hash and is very fast. The catch: it's been cryptographically broken since the mid-2000s — practical collision attacks are well documented, which is why it must never be used for passwords, certificates, or signatures. It's still fine for non-security purposes like cache keys, deduplication, and quick checksums where an attacker has no incentive to forge a match. Generate one with our MD5 generator.
SHA-256: secure integrity
SHA-256, part of the SHA-2 family standardised by NIST, produces a 256-bit hash and remains collision-resistant with no practical attacks. It's the workhorse behind TLS certificates, software signing, and Bitcoin. Use it whenever you need to verify that data hasn't changed — file downloads, document integrity, API request signing. Try the SHA-256 generator to see it in action.
bcrypt: the one for passwords
Here's the key insight that trips up so many developers: passwords should never be hashed with MD5 or SHA-256, precisely because those are fast. Speed is great for checksums but catastrophic for passwords, because it lets attackers test billions of guesses per second against a stolen database. bcrypt is deliberately slow and includes a built-in random salt, so identical passwords produce different hashes and brute-forcing becomes impractical. Its "cost factor" lets you increase the work as hardware gets faster. See it work with our bcrypt hash generator. The OWASP Password Storage Cheat Sheet recommends bcrypt (or Argon2/scrypt) for exactly this reason.
Quick reference
- MD5 → non-security fingerprints, cache keys, deduplication. Never for security.
- SHA-256 → file integrity, signatures, certificates, blockchains.
- bcrypt (or Argon2/scrypt) → password storage, always salted and slow.
Identifying an unknown hash
Inherited a database full of mystery hashes? The length and format are big clues — 32 hex characters usually means MD5, 64 means SHA-256, and a string starting with $2y$ is bcrypt. Our hash identifier can narrow it down for you. For the deeper "why fast hashing fails for passwords" story, see our companion guide on creating strong passwords.
Bottom line
Match the tool to the job: MD5 for trivial fingerprints, SHA-256 for integrity, and a slow salted algorithm like bcrypt for passwords. Choosing the wrong one isn't a style preference — it's the difference between a database breach that's contained and one that's catastrophic.