Security5 min read

MD5 vs SHA: A Story of Two Hash Functions and When to Use Each

hashingmd5shasecuritycryptography

In 1996, researchers discovered weaknesses in the MD5 hash function. By 2004, they had demonstrated full collision attacks. By 2008, a team had used MD5 collisions to forge a rogue SSL certificate that browsers trusted without any warning. By 2012, the Flame malware had used an MD5 collision to forge a Microsoft code signature and spread itself to millions of machines.

And yet in 2025, I still find MD5 checksums in production codebases. Not because developers are careless, but because understanding when a hash function is "broken" requires understanding what hash functions actually do, and what "broken" means in practice.

What a Hash Function Does

A hash function takes an input of any size and produces a fixed-length output called a digest or hash. The same input always produces the same output. A tiny change to the input produces a completely different output. This property, called the avalanche effect, is what makes hashes useful for verifying data integrity.

If you hash a file and record the digest, anyone else who hashes the same file should get the same digest. If even one byte of the file changes, the digest looks completely different. Try it yourself with the SHA Hash tool or the MD5 Hash tool. Type in any text and watch the hash change with every character you add.

What Makes MD5 Broken

MD5 produces a 128-bit hash. The weakness is in collision resistance: given enough computation, it is possible to find two different inputs that produce exactly the same MD5 hash. This is called a collision attack.

For password storage, collisions matter enormously. If an attacker can find a different string that hashes to the same value as your password, they can authenticate without ever knowing the actual password. For a simple file integrity check where you control both sides of the comparison and no attacker is involved, MD5 might still be technically acceptable. But the moment you use MD5 for anything where an adversary might try to substitute data, you have a genuine vulnerability.

Where SHA Fits In

SHA stands for Secure Hash Algorithm. SHA-1, the first widely used version, is now also considered broken for cryptographic purposes. SHA-256 and SHA-512, both part of the SHA-2 family, remain secure against all known attacks.

SHA-256 produces a 256-bit digest. SHA-512 produces a 512-bit digest. For file integrity verification, digital signatures, HMAC authentication, and data deduplication, SHA-256 is the current baseline recommendation from every major security authority.

The SHA Hash tool on this site supports SHA-256, SHA-384, and SHA-512. All three run in your browser using the Web Crypto API, so the computation happens locally and your data stays private.

The Password Storage Problem

Here is where many developers get tripped up: neither MD5 nor SHA is appropriate for storing passwords. The reason is counterintuitive. Both algorithms are designed to be fast. Fast is exactly what you do not want when hashing passwords.

A fast hash means an attacker with a GPU can try billions of password guesses per second. SHA-256 can be computed at rates exceeding ten billion operations per second on consumer hardware. At that speed, brute-forcing a weak password takes seconds.

For passwords, you need a slow hash function designed specifically to be expensive to compute. bcrypt, scrypt, and Argon2 are built for this purpose. They include a cost factor you can increase as hardware gets faster. The bcrypt tool on this site lets you hash and verify passwords using bcrypt directly in the browser, which is a useful way to understand cost factors and verify your implementation behaves as expected.

A Practical Decision Guide

The choice of hash function comes down to what you are protecting against:

  • File integrity where you control both sides: SHA-256 is strong and appropriate
  • Password storage: use bcrypt or Argon2, not MD5, not SHA
  • Digital signatures: SHA-256 as part of a proper signature scheme
  • Checksums for deduplication in a closed internal system: SHA-256 or even MD5 if performance matters and no adversary can tamper with the data
  • Legacy protocols that require MD5: acceptable for compatibility, not for security

Use SHA Hash for integrity verification and HMAC. Use bcrypt for passwords. Keep MD5 only for non-security checksums where legacy compatibility requires it. The distinction matters every time you choose how to store or verify something important.