MD5 vs SHA-256 vs SHA-3: Which Hash Should You Use?

Picking a hash function looks simple until you realize "hash" covers everything from a 1990s checksum to a modern parallel tree construction. MD5, SHA-256, and SHA-3 are the three names you'll encounter most often, and they are not interchangeable: they differ in output size, internal design, speed, and — most importantly — security status. This guide compares them head to head, explains why they differ, and gives you a use-case-driven decision framework so you can pick the right tool instead of copying whatever StackOverflow suggested in 2014.

If you want the underlying mechanics first, start with how hashing works; this article assumes you already know what a one-way function and a collision are.

The comparison at a glance

A few things jump out. The two "very fast / fast" algorithms at the top are also the two that are cryptographically broken — speed and a long history are not the same as security. SHA-256 and SHA-3 share the same security posture (no practical collisions) but are built on completely different foundations, which is precisely why having both matters.

MD5: fast, ubiquitous, and broken

MD5 produces a 128-bit digest using the Merkle–Damgård construction, and it is genuinely fast. It is also cryptographically dead. Practical collision attacks have existed since the mid-2000s — researchers can produce two different inputs with the same MD5 digest on commodity hardware in seconds, and this has been weaponized into forged certificates and malicious file pairs.

That means MD5 must never be used anywhere collision resistance matters: signatures, certificates, deduplication where an attacker controls inputs, or integrity checks against a motivated adversary. Its only defensible modern use is as a non-security checksum — detecting accidental corruption in a file transfer where nobody is trying to fool you. Even there, a 128-bit output and broken status make it a poor default. See MD5 explained for the full breakdown of the attacks and the few places it lingers legitimately.

SHA-1: deprecated, do not use

SHA-1 is the 160-bit successor to MD5 and shares its Merkle–Damgård lineage. It held up longer, but the SHAttered attack in 2017 demonstrated a practical collision, and chosen-prefix collisions followed. Browsers, certificate authorities, and Git hosting have all moved off it for security-critical purposes.

If you are choosing a hash today, SHA-1 is never the answer — it offers no advantage over SHA-256 and carries a known break. Treat it the way you treat MD5: legacy compatibility only, never new designs. SHA-1 explained covers its history and the migration path.

SHA-256: the secure default

SHA-256, part of the SHA-2 family standardized in 2001, is the workhorse of modern cryptography. It produces a 256-bit digest, also via Merkle–Damgård, and despite sharing that construction with MD5 and SHA-1 it has resisted all collision attacks. Critically, it benefits from dedicated CPU instructions (Intel SHA Extensions, ARMv8 crypto extensions) that make it extremely fast on modern hardware — often faster in practice than software SHA-3.

SHA-256 secures TLS certificates, Bitcoin, Git's newer object model, and countless signature schemes. If you have no specific reason to choose otherwise, SHA-256 is the correct default for general-purpose cryptographic hashing. Its main structural quirk is that, like all plain Merkle–Damgård hashes, it is vulnerable to length-extension attacks — more on why that matters below. SHA-256 explained goes deep on its round function and why it has held up.

SHA-3 / Keccak: a different foundation

SHA-3 is not an incremental upgrade to SHA-2 — it is a deliberately different design, selected through a public competition and standardized in 2015. It uses the sponge construction built on the Keccak permutation rather than Merkle–Damgård. Data is "absorbed" into a large internal state, then output is "squeezed" out, which gives the family useful flexibility (the same primitive yields SHAKE extendable-output functions).

The sponge design has two practical consequences. First, SHA-3 is not vulnerable to length-extension attacks by construction — the internal state is larger than the output, so knowing the digest doesn't let you continue the computation. Second, because it shares no structural DNA with SHA-2, a future cryptanalytic breakthrough against Merkle–Damgård would not automatically threaten SHA-3. That design diversity is its main selling point. In pure software it is often somewhat slower than hardware-accelerated SHA-256, which is why it's a deliberate choice rather than a universal default. SHA-3 / Keccak explained covers the sponge in detail.

BLAKE3: when you need raw speed

If throughput is your bottleneck — hashing large files, content-addressed storage at scale, or deduplication pipelines — BLAKE2 and BLAKE3 are worth knowing. BLAKE3 uses a Merkle tree structure, which lets it parallelize across cores and SIMD lanes, making it the fastest of this group while remaining cryptographically strong (no known collisions). It also supports extendable output and a built-in keyed mode. It is less universally available in standard libraries than SHA-2, so reach for it when speed genuinely matters and you control both ends.

Choosing by use case

The right hash depends almost entirely on what you're doing. Here's how the use cases break down.

File integrity and checksums

For verifying a download against a published digest, or detecting bit-rot, you need collision resistance only if an attacker might tamper with both the file and the published hash. In a security context (verifying a release artifact), use SHA-256. For pure accidental-corruption detection with no adversary, even a fast non-cryptographic checksum works, but SHA-256 or BLAKE3 are fine and keep you safe by default. Never use MD5 or SHA-1 for integrity you actually rely on.

Content addressing and deduplication

Content-addressed stores (Git, IPFS-style systems, dedup backends) use the hash as an identity. A collision here means two distinct objects collapse into one — potentially a data-corruption or security incident if inputs are attacker-controlled. Use a collision-resistant hash: SHA-256 is standard, and BLAKE3 is excellent when ingest speed dominates. MD5-based dedup is a latent vulnerability whenever inputs aren't fully trusted.

Digital signatures and certificates

Signatures inherit the security of their hash — a collision in the hash is a forgery in the signature. This is the strictest requirement. Use SHA-256 or stronger (SHA-384/SHA-512, or SHA3-256). MD5 and SHA-1 have both been used to forge certificates in the wild; they are categorically disqualified here.

HMAC and message authentication

For authenticating messages with a shared key, use HMAC rather than naively concatenating a key and message — the latter is exactly what length-extension attacks exploit. HMAC's nested construction neutralizes length extension even when built on a Merkle–Damgård hash, so HMAC-SHA-256 is perfectly safe and is the common choice. See HMAC explained for why the construction matters. If you ever need a raw keyed-hash MAC without HMAC's wrapping, SHA-3 (or a KMAC) and BLAKE3's keyed mode are designed to be safe directly.

Why length extension steers some designs

A length-extension attack lets someone who knows hash(secret || message) and the length of the secret compute hash(secret || message || padding || extra) without knowing the secret. This breaks the naive "prefix a secret key" MAC. Three robust ways around it: use HMAC (works on any hash), use SHA-3 (sponge construction is immune), or use a truncated SHA-512 variant like SHA-512/256 (truncation hides enough internal state to block the attack). If your design hashes secrets directly, prefer one of these over plain SHA-256.

Passwords: none of these — use a slow KDF

This is the single most important caveat in this article. MD5, SHA-256, and SHA-3 are all the wrong tool for storing passwords. They are designed to be fast, which is exactly what you don't want — speed lets an attacker who steals your database try billions of guesses per second on GPUs.

For passwords, use a deliberately slow, memory-hard key derivation function: Argon2 (preferred for new systems), bcrypt, or scrypt. These add salting and a tunable cost factor so each guess is expensive. Hashing a password with bare SHA-256 — even "salted" — is a well-known mistake that leads to mass credential cracking after a breach. Read the password hashing guide before you build any authentication system.

Final recommendations

• General-purpose cryptographic hash: SHA-256. It's the secure default, widely supported, and hardware-accelerated.
• Need length-extension resistance or design diversity: SHA-3 (or SHA-512/256, or wrap in HMAC).
• Maximum throughput: BLAKE3.
• Message authentication: HMAC-SHA-256.
• Passwords: Argon2 / bcrypt — never a plain hash.
• MD5 / SHA-1: legacy compatibility only; never in new security-sensitive designs.

In short: SHA-256 unless you have a specific reason, SHA-3 or HMAC when length extension is in play, BLAKE3 for speed, and a real KDF for passwords.

Try it yourself

You can compare hashes side by side in your browser with Hash Generator — it produces MD5, SHA-256, SHA-3, and more from the same input at once, entirely client-side. Everything runs locally in WebAssembly, so nothing you type is ever uploaded. It's a fast way to see how the same string yields a 128-bit MD5 digest versus a 256-bit SHA-256 or SHA3-256 output, and to build intuition for the differences described above. Head to Hash Generator and start comparing.