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

If you've ever downloaded a Linux ISO and seen both an MD5SUM and a SHA256SUM file next to it, you've probably wondered: why two? Most modern projects publish only SHA-256 today. MD5 is still everywhere — but mostly for legacy reasons, not because anyone recommends it for new work.

This is the practical comparison: when MD5 is fine, when it absolutely isn't, and why SHA-256 became the default for almost everything that matters.

The mechanical differences

Property	MD5	SHA-256
Year published	1991 (Ronald Rivest)	2001 (NIST / NSA)
Output size	128 bits (32 hex chars)	256 bits (64 hex chars)
Block size	512 bits	512 bits
Rounds	64 (4 × 16)	64 complex rounds
Collision attack	2⁻¹⁸ (seconds on a laptop)	None known (2²⁵⁶ brute force)
Preimage attack	2¹²³ (theoretical)	2²⁵⁶ (theoretical)
Hardware acceleration	None standard	Intel SHA-NI, ARMv8.2 crypto

The "MD5 is faster" myth

For 20 years the conventional wisdom was that MD5 is faster than SHA-256 — and on paper, it is. MD5 does fewer arithmetic operations per block. But modern CPUs have SHA-256 hardware instructions that MD5 doesn't get. Intel's SHA-NI extension (available since 2015 on most processors) makes a single SHA-256 round about as fast as a single MD5 round. On Apple Silicon and modern ARM server chips, the gap is similar.

For pure-JavaScript or interpreted-language implementations (no hardware acceleration), MD5 is still ~2× faster. But the moment you're using the platform's native crypto library, the difference is small. The decision should be about security, not speed.

Why MD5 is broken

"Broken" doesn't mean random people can decrypt MD5 hashes. MD5 is still a one-way function — you can't go from 5d41402abc4b2a76b9719d911017c592 back to hello by math alone. What's broken is the collision resistance: the ability to find two different inputs that hash to the same value.

In 2004, researchers Wang and Yu published an algorithm that finds MD5 collisions in about an hour. By 2008, the time was down to seconds. That same year, a team built a rogue Certificate Authority by exploiting MD5 collisions to forge a signed TLS certificate. After that, every major browser disabled MD5 for certificate signing. By 2013, Microsoft disabled MD5 for code signing on Windows.

Practical implication: if anyone might benefit from making two different files hash to the same value (a malicious download vs. the legitimate one, a forged digital signature vs. the real one, two PDFs that "say" different things but pass the same integrity check), MD5 cannot defend against that. SHA-256 still can.

Where MD5 is still acceptable

• Detecting accidental corruption in file transfers when no adversary is involved (e.g., verifying a copy completed correctly between two trusted machines).
• Deduplication keys where collisions just mean "this file looks the same so we link them" — and the deduplication system has its own conflict resolution.
• Cache invalidation for small internal caches where collisions are tolerable.
• Legacy interoperability — talking to systems that only emit MD5.

Even in these cases, SHA-256 isn't going to hurt you. The storage difference is 32 vs. 64 hex characters; the speed difference on modern hardware is negligible. The only reason to actively choose MD5 today is when something else mandates it.

What SHA-256 gives you

SHA-256 is the default hash function for TLS 1.3, code signing (Authenticode, Apple's notarization, Linux package signatures), Bitcoin, Git's next-generation object IDs, blockchain transactions, and most modern file integrity checking. When you see "SHA-256 checksum" on a download page, it's because the publisher wants you to be able to cryptographically prove the file is authentic, even if your network is compromised.

It's also what bcrypt, scrypt, Argon2, and PBKDF2 use internally — but please don't use plain SHA-256 directly on passwords (more on that in bcrypt vs Argon2).

The two-minute decision tree

• Storing user passwords? Neither. Use bcrypt or Argon2id.
• Signing or verifying anything someone might want to tamper with? SHA-256.
• Publishing a file checksum for users to verify? SHA-256.
• Building Merkle trees, content-addressable storage, or anything blockchain-adjacent? SHA-256.
• Hashing inside your own infrastructure where attackers can't reach? Either works. SHA-256 is the safe default.
• Forced to interoperate with an old system? Match what it uses. Document why.