MD5 vs SHA-256 — Which Hash Should You Use?

MD5 and SHA-256 are the two hash algorithms developers meet most often — in checksums, ETags, cache keys, download verification, and (unfortunately) legacy password tables. One of them is cryptographically broken; the other remains a workhorse of modern security. Yet MD5 has not disappeared, because for some jobs it is still perfectly fine. This guide compares the two honestly: where the speed difference matters, how MD5 and SHA-1 were actually broken, and a simple decision rule for choosing the right algorithm for your use case.

The Two Algorithms at a Glance

                      MD5                    SHA-256
Published             1992                   2001 (SHA-2 family)
Digest size           128 bits (32 hex)      256 bits (64 hex)
Relative speed        Very fast              Fast (roughly 2-3x slower in software)
Collisions found?     Yes — since 2004,      None known; best attacks
                      now trivial            are far from practical
Security use today    Forbidden              Recommended
Non-security use      Acceptable             Also fine

echo -n "hello" | md5sum
5d41402abc4b2a76b9719d911017c592

echo -n "hello" | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Both are deterministic one-way functions: same input, same output, and there is no feasible way to reverse the digest back into the input. The difference is what an attacker can do with each.

Speed vs Security — Why Faster Is Not Better

MD5 is faster than SHA-256 in pure software, and for hashing gigabytes of log files that can be a real saving. But in security contexts, speed works for the attacker: the faster a hash computes, the faster someone can grind through candidate inputs looking for a match. Modern GPUs compute tens of billions of MD5 hashes per second. Meanwhile, on recent CPUs with SHA extensions, hardware-accelerated SHA-256 often matches or beats MD5 anyway — so the classic "MD5 because it is faster" argument is mostly obsolete.

• No attacker in the picture? Speed is a legitimate tie-breaker.
• Attacker in the picture? Speed is a liability, and MD5's broken collision resistance disqualifies it entirely.

How MD5 and SHA-1 Were Actually Broken

A collision is two different inputs producing the same digest. Collision resistance is the property real attacks target, and history shows how it falls:

• 2004 — MD5 falls. Xiaoyun Wang's team published the first practical MD5 collisions. Within a few years, generating a collision took seconds on an ordinary PC.
• 2008 — Rogue CA certificate. Researchers used MD5 collisions to forge a certificate authority certificate that browsers would have trusted, forcing the industry to drop MD5 from certificate signing.
• 2012 — Flame malware. The Flame espionage malware used a novel MD5 chosen-prefix collision to forge a Microsoft code-signing certificate and pass itself off as a legitimate Windows update.
• 2017 — SHA-1 falls. Google and CWI Amsterdam announced SHAttered: two different PDF files with the same SHA-1 digest. SHA-1 was deprecated for certificates and signatures industry-wide.

The lesson: hash algorithms do not fail all at once. They fail gradually in research papers years before they fail catastrophically in the wild — which is why "no one has attacked my app yet" is not a defense.

When MD5 Is Still Perfectly Fine

MD5 is broken against adversaries, not against accidents. Random corruption does not craft colliding inputs. Legitimate uses today:

• Detecting accidental corruption — verifying an internal file copy or backup completed intact
• Cache keys and ETags — mapping content to a short identifier where a deliberate collision gains an attacker nothing
• Deduplication — spotting duplicate records or files inside your own trusted pipeline
• Partitioning / sharding — spreading keys across buckets evenly
• Interop with legacy systems — when an existing protocol or vendor API demands MD5

The test is simple: would a malicious actor benefit from producing two inputs with the same hash, or from forging a file that matches a published hash? If yes, MD5 is disqualified. If no human adversary is part of the threat model, MD5 is fine — though SHA-256 costs so little extra that many teams standardise on it everywhere just to avoid the judgement call.

When You Need SHA-256 or Stronger

• Download and release verification — publishing checksums users rely on to detect tampering
• Digital signatures and certificates — the digest is what actually gets signed
• HMACs and API request signing — use HMAC-SHA256, never plain concatenation
• Content-addressed storage — systems where the hash is the identity (Git is migrating from SHA-1 to SHA-256 for exactly this reason)
• Blockchain, audit logs, tamper-evident records — anywhere integrity is the entire point

// Node.js: SHA-256 costs one line, same as MD5
const crypto = require('crypto');

const sha256 = crypto.createHash('sha256').update(fileBuffer).digest('hex');
const hmac   = crypto.createHmac('sha256', apiSecret).update(body).digest('hex');

Passwords: Neither MD5 Nor SHA-256

This trips up many developers: SHA-256 being "secure" does not make it right for passwords. Both MD5 and SHA-256 are fast, and fast is fatal for password storage — a GPU rig can test billions of guesses per second against a leaked table of fast hashes. Passwords need algorithms that are deliberately slow and salted: bcrypt, scrypt, or Argon2 (the current recommendation). These let you tune the cost so each guess takes tens of milliseconds instead of nanoseconds, turning a weekend cracking job into centuries.

Frequently Asked Questions