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

If you are choosing between MD5 and SHA-256 for anything that a security decision depends on, the answer is settled and has been for years: use SHA-256. The interesting question is not which one wins but why MD5 lost, what specific property it lost, and which of the jobs people still use it for are genuinely unaffected. That distinction is what keeps engineers arguing in code review long after the cryptographers stopped.

For the broader background on how hash functions work and what properties they are supposed to guarantee, see The Complete Guide to Cryptographic Hashing. This post narrows in on the head-to-head comparison and the decision you actually have to make.

The Short Comparison

	MD5	SHA-256
Digest size	128 bits / 32 hex chars	256 bits / 64 hex chars
Published	1992	2001
Family	MD	SHA-2
Collision resistance	Broken (2004; chosen-prefix collisions practical today)	Intact — no practical attack
Pre-image resistance	Not practically broken	Intact
NIST status	Not approved for security use	Approved standard
Hardware acceleration	No	Yes, on most modern CPUs
Safe for	Non-adversarial checksums only	Everything except password storage

Neither algorithm belongs anywhere near password storage — that job needs a deliberately slow, salted function like bcrypt, Argon2, or PBKDF2. Speed is a virtue for both of these algorithms and a liability for credentials.

What "Broken" Actually Means for MD5

MD5 has not been reversed. You cannot feed a digest into some machine and get the original file back, and no one has demonstrated a practical pre-image attack. If that were the standard, MD5 would still be standing.

What collapsed is collision resistance: the guarantee that nobody can find two distinct inputs producing the same digest. Wang and Yu published a practical collision technique in 2004. The attack has only gotten cheaper since, and today the relevant capability is the chosen-prefix collision — an attacker picks two arbitrary, meaningfully different starting documents and computes suffixes that force both to land on the same MD5 digest. That is not a laboratory curiosity. It is the difference between "collisions exist somewhere in the math" and "I can hand you a benign installer and a malicious installer with identical MD5 sums."

Once collisions are cheap, everything built on top of the hash inherits the weakness. Digital signatures sign the digest, not the document, so a collision lets a valid signature be transplanted onto a different file. Certificate authorities that hashed with MD5 were shown to be forgeable. Any "the file is unchanged because the MD5 matches" claim becomes unfounded the moment an adversary is in the picture. Hash Collisions Explained walks through how these attacks are constructed and why the birthday bound makes a 128-bit digest such a soft target.

SHA-256 has none of this. The best published attacks against SHA-256's collision resistance reach only heavily reduced-round variants of the compression function — an academic result about the design margin, not a threat to the full algorithm. There is no known way to produce a SHA-256 collision faster than brute force, and brute force against a 256-bit digest means roughly 2^128 work, which is not a number that shrinks with better hardware.

The Speed Question Is Mostly a Trap

MD5 is often described as the fast option, and in a plain software implementation it is: fewer rounds, smaller state, less work per 512-bit block. Benchmarks typically show it somewhere between 1.5x and 3x the throughput of a naive SHA-256.

Two things flatten that advantage in practice.

First, hardware acceleration. Intel SHA Extensions and ARMv8 cryptographic instructions compute SHA-256 rounds natively. On a CPU with those instructions, SHA-256 frequently matches or beats MD5 outright — the algorithm cryptographers recommend also happens to be the one silicon designers optimized. MD5 gets no such help.

Second, I/O dominates. Hashing a 4 GB ISO is bounded by how fast the bytes come off the disk or the network, not by the compression function. Whatever fraction of a second separates the two algorithms disappears into read latency. In a browser, hashing a file you dropped onto the page is limited by the File API and memory bandwidth long before the digest math matters.

The honest summary: if you are hashing billions of short records in a hot loop and no attacker exists, MD5's speed can be a real engineering input. In every other scenario, choosing MD5 for performance is optimizing something you cannot measure at the cost of something you cannot recover.

Digest Length and Practical Handling

The length difference is not only a security margin, it is an ergonomic one. A 32-character MD5 fits comfortably in a log line or a filename; a 64-character SHA-256 wraps in most terminals. That is genuinely why MD5 lingers in tooling written before 2010.

It also gives you a free identification trick. Count the hex characters in a digest you have been handed: 32 means MD5, 40 means SHA-1, 64 means SHA-256, 128 means SHA-512. If a download page lists a 40-character sum, you are being asked to verify with SHA-1 — which fell to the SHAttered attack in 2017 and has been formally deprecated by NIST, so treat it exactly as you would treat MD5. You can still compute one with the SHA-1 Hash Generator when a legacy system demands it, but do not let a match reassure you about tampering.

Where MD5 Is Still Defensible

There is a narrow, legitimate band of uses, and it is defined entirely by the absence of an adversary:

• Detecting accidental corruption. A file copied over a flaky network, a tape restore, a disk with a failing sector. Random bit flips do not produce MD5 collisions; you are not fighting anyone.
• Deduplication and cache keys. Fingerprinting content to avoid storing it twice, when the content is internal and nobody profits from forcing a collision. Note the caveat: if users can upload the content being deduplicated, an adversary is in the loop, and a deliberate collision could make one user's file resolve to another's.
• Verifying legacy publisher sums. Plenty of mirrors and vendor pages still list only an MD5. Checking it is better than checking nothing — it catches a truncated download. It just is not evidence against tampering.

That last case is why an MD5 Hash Generator remains a practical tool rather than a museum piece. The right posture is to compute the sum, confirm the download completed intact, and understand precisely what you have and have not proven. For a fuller treatment of that line, see Is MD5 Still Safe to Use?.

Making the Switch

When SHA-256 is the right answer — which is whenever the hash backs a security decision — the migration is usually mechanical. Every mainstream language exposes SHA-256 in its standard library, browsers expose it through the Web Crypto API, and the only real work is widening database columns from 32 to 64 characters and republishing any digests you had committed to.

For one-off verification, compute the digest of your local copy with the SHA-256 Hash Generator and check it against the publisher's value using the Hash Comparison & File Integrity Verifier instead of scanning 64 hex characters by eye. Near-miss digests are exactly what a substitution attack produces, and human pattern matching is bad at catching a changed character in the middle of a long random string. Both tools run entirely in your browser, so the file and the digest never leave your machine.

If you are also weighing SHA-256 against its larger sibling, SHA-256 vs SHA-512 covers why the longer digest is sometimes the faster one.

The Bottom Line

MD5 and SHA-256 are not two points on a security spectrum where you trade a little safety for a little speed. MD5 has lost a specific, essential property — collision resistance — and no amount of double-hashing or salting restores it. SHA-256 retains every property a cryptographic hash is supposed to have, is a NIST standard, and on modern hardware often runs just as fast.

Use SHA-256 by default. Reach for MD5 only when you can point at a specific legacy sum you are matching or a specific non-adversarial checksum you are computing, and only while knowing exactly what that match does and does not prove.