MD5 vs SHA-256: Which Hash to Use and When It Matters

Cryptographic hash functions are one of those foundational tools that appear everywhere — in digital signatures, file verification, password storage, data integrity checks — and yet the difference between using MD5 and SHA-256 is often misunderstood, sometimes catastrophically so.

The short answer: MD5 is broken for any security-sensitive purpose. SHA-1 is deprecated and should not be used for new applications. SHA-256 is the current standard for general security use. But the longer answer depends on what you're actually trying to do.

What a hash function does

A cryptographic hash function takes an input of any size and produces a fixed-size output (the hash or digest). It has three important properties:

• Deterministic: The same input always produces the same output.
• One-way: Given the hash, you cannot recover the original input (in theory — and in practice for strong algorithms).
• Collision-resistant: It should be computationally infeasible to find two different inputs that produce the same hash.

This last property — collision resistance — is where older algorithms have failed.

MD5: fast, popular, broken

MD5 was designed by Ron Rivest in 1991 and produces a 128-bit (32 hex character) digest. It was widely used throughout the 1990s and 2000s for file checksums, password storage, and digital signatures.

In 2004, researchers demonstrated practical collision attacks against MD5. In 2008, a team created a rogue CA certificate by exploiting MD5 collisions. By 2012, the Flame malware had forged a Microsoft code signing certificate using an MD5 collision attack.

MD5 is broken for any use case where collision resistance matters — which includes digital signatures, certificate fingerprinting, and file integrity verification in adversarial contexts. An attacker can craft two different files that produce the same MD5 hash.

MD5 is still acceptable for non-security checksums (verifying that a file wasn't accidentally corrupted during transfer, where there's no adversarial party). But if someone could benefit from making two different things look identical to your hash check, MD5 is not safe.

SHA-1: deprecated, not dead

SHA-1 produces a 160-bit (40 hex character) digest. It was the replacement for MD5 and remained the standard for many years. Major browsers stopped accepting SHA-1 TLS certificates in 2017, and Git's historic use of SHA-1 for commit identifiers has been a subject of ongoing concern (though exploiting it in a Git context requires specific conditions).

Practical collision attacks against SHA-1 were published in 2017 (the SHAttered attack). SHA-1 should not be used for any new application that requires collision resistance. Existing systems that still use it should migrate to SHA-256.

SHA-256: the current standard

SHA-256 is part of the SHA-2 family, producing a 256-bit (64 hex character) digest. No practical attack has been demonstrated against SHA-256. It is the standard for TLS certificates, code signing, Bitcoin's proof-of-work algorithm, and most modern security applications.

SHA-512 produces a 512-bit digest and is sometimes preferred for specific applications (it can be faster than SHA-256 on 64-bit systems for large inputs, though the difference is rarely significant in practice).

SHA-3: the alternative

SHA-3 (Keccak) was standardized by NIST in 2015. It's not a replacement for SHA-2 but an alternative with a different internal design. The motivation was defense in depth — if a weakness were found in SHA-2's Merkle-Damgard construction, SHA-3's completely different sponge construction would not share it. For most applications, SHA-256 is the right choice; SHA-3 is available if your threat model requires algorithmic diversity.

Password storage is a different problem

All of the above applies to general-purpose hashing. Password storage is different. SHA-256 is a fast hash function — that's what makes it good for file checksums and signatures, but it's a problem for passwords.

For passwords, you want a slow hash — one designed to be computationally expensive to compute, so that brute-force attacks are costly. The recommended algorithms for password hashing are Argon2 (the winner of the Password Hashing Competition), bcrypt, and scrypt. For a practical look at entropy and password length, see Building Passwords That Actually Hold Up. A database of SHA-256-hashed passwords can be attacked at billions of guesses per second on a modern GPU. A database of Argon2-hashed passwords might allow only thousands.

If you are implementing authentication: use Argon2, bcrypt, or scrypt. Never use MD5, SHA-1, or even SHA-256 alone for password storage.

When MD5 and SHA-1 are still fine

There are legitimate uses for these older algorithms where security is not the concern:

• Generating unique identifiers or cache keys from data (where predictability of collision is acceptable)
• Checking accidental file corruption where no adversary is involved
• Legacy system compatibility where you cannot control the algorithm
• Non-security checksums in internal tools

The ToolsKit Hash Generator supports MD5, SHA-1, SHA-256, and SHA-512. For quick checksums, file verification testing, or understanding what a particular hash algorithm produces from a given input, any of these are appropriate — the choice depends on what you're doing with the result.

Summary: which to use

• Digital signatures, certificates, code signing: SHA-256 minimum.
• File integrity verification (adversarial): SHA-256 or SHA-512.
• File checksums (non-adversarial): MD5 is fine for convenience; SHA-256 is better practice.
• Password storage: Argon2, bcrypt, or scrypt. Never MD5, SHA-1, or bare SHA-256.
• HMAC (message authentication): HMAC-SHA256 is standard. HMAC-MD5 is outdated.