MD5 vs SHA-1 vs SHA-256: which hash should you use?

Short answer: use SHA-256. MD5 and SHA-1 are cryptographically broken, meaning attackers can manufacture two different inputs that produce the same hash. They are still acceptable for non security tasks like cache keys and duplicate detection of trusted data, but for anything an attacker could influence, SHA-256 or better is the floor.

You can generate all three side by side in the Hash Generator, entirely in your browser, which makes the differences below easy to see with your own data.

What these algorithms have in common

All three are cryptographic hash functions: they take input of any length and produce a fixed length digest. The same input always produces the same digest, a tiny change to the input changes the digest completely, and the function only runs one way. There is no method to recover the input from the digest other than guessing inputs.

"Broken" has a precise meaning here, and it is narrower than most people assume.

What does "broken" actually mean?

The security property that failed is collision resistance: it should be computationally infeasible to find two different inputs with the same hash.

• For MD5, collisions can be generated in seconds on a laptop. Researchers demonstrated this in 2004, and by 2008 a team used MD5 collisions to forge a working certificate authority certificate.
• For SHA-1, Google and CWI Amsterdam published the SHAttered attack in 2017: two different PDF files with the same SHA-1 hash. The attack cost significant compute then and gets cheaper every year.

Note what has not been broken: preimage resistance. Nobody can take an MD5 digest and work backwards to an input, other than by brute force. This is why the answer to "is MD5 ever OK" is not a flat no.

Why do collisions matter in practice?

A collision attack requires the attacker to control both inputs. That maps to real scenarios more often than it sounds:

• Signatures. You sign a document by signing its hash. If an attacker can craft two documents with the same hash, one innocent and one malicious, your signature on the first is valid for the second.
• Certificates. Same mechanism: a CA signs a certificate's hash. The 2008 MD5 attack produced a rogue CA certificate this way.
• Git and content addressed storage. Two different files with the same hash break the assumption that the hash identifies the content.

If the attacker only controls one input, for example they want a file matching a hash you already published, that is a second preimage attack, and no practical one exists even against MD5. But designing around that distinction is fragile, and there is no cost advantage to justify it: SHA-256 is fast.

When are MD5 and SHA-1 still acceptable?

For non adversarial integrity, the older algorithms still work fine:

• Detecting accidental corruption in file transfers between your own systems
• Cache keys and content deduplication over data you already trust
• Partitioning or bucketing keys in a database
• Checksums a legacy protocol requires

The test is simple: could an attacker benefit from producing a collision? If no adversary is in the picture, MD5 is just a fast checksum. The moment the hash carries security weight, it is the wrong tool.

Where you must not use them

• TLS certificates and any digital signature
• Verifying downloaded software against a published hash
• Webhook or API payload signatures
• Anything labeled "integrity" in a security review

Browsers and CAs stopped accepting SHA-1 certificates back in 2017 for exactly this reason.

What about passwords?

None of these three, including SHA-256, is appropriate for storing passwords. They are all designed to be fast, and fast is fatal for password hashing: modern hardware computes billions of SHA-256 hashes per second, so an attacker with a leaked database can brute force weak passwords quickly. Password storage needs a deliberately slow, salted algorithm like bcrypt, scrypt, or Argon2. The distinction is covered in depth in SHA-256 vs HMAC vs bcrypt.

SHA-256, SHA-512, and the SHA-2 family

SHA-256 belongs to the SHA-2 family, which also includes SHA-512 and truncated variants like SHA-384. SHA-512 is not meaningfully "more secure" for any realistic threat; both are far beyond feasible attack. SHA-512 can actually be faster on 64 bit CPUs because it processes larger blocks, which is why some tools default to SHA-512 for file checksums.

SHA-3 exists as a structurally different alternative, standardized in 2015 as insurance in case a weakness is ever found in SHA-2. None has been. There is no reason to migrate to SHA-3, and SHA-256 remains the ecosystem default: TLS, Bitcoin, Git (in its newer object format), and most package managers all standardize on it.

Quick decision guide

To see how the same input produces radically different digests across algorithms, or to check a published checksum against a file, paste it into the Hash Generator. Hashing runs locally in your browser and your input never leaves the page.