MD5, SHA-256, BLAKE3: A Practical Guide to Hash Function Choice

Most engineers reach for SHA-256 by reflex. That's usually fine — but "usually" isn't always. Different hash functions optimise for different things, and the right choice depends on whether you need cryptographic security, raw throughput, deduplication, or a tiny fingerprint for a hash table. Here is a working developer's guide to the six you're most likely to encounter.

MD5

Output: 128 bits. Designed by Rivest in 1991. Cryptographically broken since 2004 — collisions are trivial to generate on a laptop. Despite that, MD5 still has legitimate non-security uses where you just need a fast fingerprint and don't care if an adversary can craft inputs.

Use MD5 for: file deduplication where you trust the inputs, ETag generation, cache keys, content-addressed storage of non-adversarial data. Never use MD5 for: certificates, signatures, password storage, anything where two matching hashes need to mean "same content." If an attacker can choose the input, MD5 is a security hole.

SHA-1

Output: 160 bits. Practical chosen-prefix collisions demonstrated in 2020 at roughly $45,000 of cloud compute. Retired by NIST in 2022.

Use SHA-1 for: legacy compatibility, Git's default object hashing (with collision-detection mitigations). Don't pick it for new code. Even in non-security contexts, BLAKE3 is faster and SHA-256 is more trustworthy.

SHA-256 (and the SHA-2 Family)

Output: 256 bits. Designed by the NSA, published by NIST in 2001. The current workhorse of the internet — TLS certificates, Bitcoin, Git's SHA-256 mode, Linux package signing. No practical attacks. Survived two decades of cryptanalysis without a meaningful break.

SHA-256 is the safe default for any cryptographic use case. Its slower siblings SHA-384 and SHA-512 are used where you specifically want a wider digest (post-quantum hedging, longer HMAC keys), but they cost more compute and offer no practical advantage at current threat levels.

The main critique of SHA-256 is speed. It's decent on hardware with SHA extensions (Intel SHA-NI, ARM v8 crypto), but on machines without those extensions, BLAKE3 can be 5-10× faster.

SHA-3

Output: configurable, typically 256 or 512 bits. Standardised by NIST in 2015. Built on the Keccak sponge construction — a completely different internal design from SHA-2. The point of SHA-3 was not to replace SHA-2 (which isn't broken) but to have a structurally different backup ready in case SHA-2 ever fell.

SHA-3 is slightly slower than SHA-2 in software but easier to implement in hardware. It's also the basis for the SHAKE extendable-output functions, useful when you need a hash output of arbitrary length (e.g., key derivation). For most application code, SHA-256 is still the default; reach for SHA-3 when you specifically need its sponge properties or extendable output.

BLAKE2 and BLAKE3

BLAKE2 (2012) and BLAKE3 (2020) are derived from a SHA-3 finalist. BLAKE3 in particular is engineered for speed: it parallelises across CPU cores via a tree structure, uses SIMD instructions aggressively, and has a security margin comparable to SHA-256.

On a modern machine, BLAKE3 hashes a multi-gigabyte file at around 6 GB/s — fast enough that you're bottlenecked by disk or memory, not by the hash. Use BLAKE3 for: large file integrity checking, content-addressed storage at scale, anywhere SHA-256 is "the right choice but feels too slow." The catch: it's newer, not yet a NIST standard, and not supported in most browsers' SubtleCryptoAPIs. For server-side code in Rust, Go, or Python, it's an excellent choice. For browser code, you're stuck with SHA-2 unless you ship WASM.

xxHash

Output: typically 64 or 128 bits. Designed for speed, not security. xxHash is what you reach for when you need a hash table key, a Bloom filter input, or a checksum for transient data — situations where adversarial collisions are not a threat model and you want to spend as few cycles as possible per byte.

Don't use xxHash for anything where matching hashes imply matching content under adversarial conditions. It's a non-cryptographic hash, full stop.

Quick Reference

• Cryptographic, default choice: SHA-256
• Cryptographic, need speed: BLAKE3
• Cryptographic, need a different design family: SHA-3
• Cryptographic, need wider output: SHA-512 or SHAKE-256
• Non-cryptographic, dedup/cache/ETag: MD5 or BLAKE3
• Non-cryptographic, hash table / Bloom filter: xxHash
• Password storage: none of the above — use Argon2id, scrypt, or bcrypt

That last point catches people. A password hashing function is intentionally slow — the opposite of what every general-purpose hash optimises for. Don't store passwords with SHA-256 or BLAKE3 directly. Use a password-specific KDF.