Security

MD5 vs SHA-256: Which One to Use, and Why MD5 Still Has a Job

MD5 is broken the moment someone chooses the input on purpose. SHA-256 is not. MD5 still catches an ordinary corrupted download, and knowing which is which is the whole question.

The same two shapes feed an MD5 block on the left and merge into one output; on the right they feed a SHA-256 block and stay as two separate outputs.

MD5 and SHA-256 both turn any input into a fixed-length digest, but only one of them survives someone trying to break it on purpose. MD5 is 128 bits and has been breakable since 2004: an attacker can build two different files that hash to the same MD5 digest, deliberately, on ordinary hardware. SHA-256 is 256 bits, and as of 2026 nobody has published a collision against it. Use SHA-256 whenever a file, a message or a signature might be shaped by someone who wants a specific result out of it. MD5 is still fine for exactly one job: telling you a download did not get corrupted by accident, where nobody involved is trying to fool you.

What actually differs between the two algorithms

The digest length is the visible difference, but it is not the reason one is broken and the other is not.

MD5SHA-256
Digest length128 bits, 32 hex characters256 bits, 64 hex characters
Standardised1992, RFC 13212001, FIPS 180-2, the SHA-2 family
Collisions foundYes, since 2004None published
Preimage attacksNone practicalNone practical
Safe for signatures, certificates, anything adversarialNoYes
Fine for spotting accidental corruptionYesYes, and slower for no benefit here

A short digest alone would not make an algorithm unsafe — plenty of older, narrower designs have never been broken. What happened to MD5 is specific and dated: a hash function's whole security case rests on nobody being able to find two inputs that collide, and for MD5 that stopped being true two decades ago.

Collision resistance is not preimage resistance

Two different guarantees get lumped together as "hashes can be broken," and MD5 sits on opposite sides of them.

A collision means an attacker builds two different inputs and gets to choose both of them, so both land on the same digest. In August 2004, Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu published a method that does this to MD5 in about an hour on the hardware of that year; on anything modern it takes seconds. That is a real, repeatable, practical break.

A preimage attack means an attacker starts from a digest they did not choose — one you already published — and has to find any input that produces it. Nobody has a practical preimage attack against MD5 as of 2026. That is the whole reason MD5 still catches a corrupted download: your file's checksum was never a value an attacker picked in advance, so the resistance that job actually needs is the one MD5 still has.

The distinction decides everything about whether MD5 is safe in a given spot. If an attacker can produce or influence the file before you hash it, you need collision resistance, and MD5 has none. If you are only checking that the bytes you received match ones a trusted source generated, the job needs something closer to preimage resistance, and MD5 still has enough of it for that.

What a chosen-prefix collision actually buys an attacker

The 2004 break produces two colliding blobs built from scratch — useless unless you can get both of them accepted as legitimate documents. A follow-up technique, a chosen-prefix collision, is the one that made MD5 dangerous in practice.

A chosen-prefix collision lets an attacker start from two arbitrary documents they actually want — not blobs invented for the purpose — and append carefully computed padding to each so the padded versions share an MD5 digest. In December 2008, a team including Alexander Sotirov and Marc Stevens used exactly this to forge a rogue intermediate certificate authority: they got a real certificate authority that was still signing with MD5 to sign an ordinary-looking certificate, and the padding meant that same signature was equally valid for a second certificate the researchers had built — one with the power to issue certificates for any domain, trusted by every browser that trusted MD5 signatures. That is what collision resistance buys you, stated as one sentence: without it, a signature over one document is a signature over whatever else the signer's algorithm let someone else attach to it.

Why a checksum sitting next to the file proves nothing

This part has nothing to do with which algorithm you pick. If a download page shows you a file and a checksum in the same breath, whoever can replace the file can replace the number under it in the same edit. A SHA-256 checksum on a compromised page is exactly as convincing as an MD5 one: not at all. You have verified the file against itself, not against anything independent.

Real authenticity needs the checksum — or better, a full digital signature — to arrive by a route the person who might tamper with the file does not also control: a signing key you already trust, checked with something like gpg --verify, or a checksum published somewhere separate from the download, such as a security mailing list or a different domain entirely. The hash generator will tell you honestly whether the bytes you have match the number you were given; it has no way to tell you whether that number was ever trustworthy to begin with.

When MD5 is still the right tool

Nowhere adversarial, and plenty of places that are not. MD5 remains fine, and often faster, for jobs where nobody is trying to produce a specific outcome: detecting a truncated file transfer, deduplicating files you already trust by content, tagging cached objects, or checking against a checksum published by the same team that built the software, over a channel you already trust for other reasons. None of that requires collision resistance, because nobody is crafting an adversarial input — the corruption you are checking for is accidental, not engineered.

What MD5 should never touch again: a digital signature, a certificate, a password reset token, anything where a digest stands in for a document someone else might have shaped to collide with it. SHA-256 costs almost nothing extra on current hardware and removes the question entirely.

The hash generator computes MD5 and SHA-256 side by side for the same text or file, so you can watch how differently they respond to a one-character change, and paste in a published checksum to check against either. Nothing leaves your machine.

If you want the full model behind all of this — what a digest actually is, why it cannot be reversed, and where hashing stops being the right tool at all — what a hash function is, and what it is not covers the rest of it.

Frequently asked questions

Is MD5 still safe to use?

Not for anything adversarial. An attacker can build two different files that produce the same MD5 digest on purpose, which breaks any use where a digest substitutes for a document, such as a signature or a certificate. For catching an accidentally corrupted download, MD5 is still fine, because nobody engineered your file to collide with anything.

What is the difference between a collision attack and a preimage attack?

A collision attack lets an attacker choose two different inputs and make them share a digest, which is what broke MD5 in 2004. A preimage attack starts from a digest the attacker did not choose and tries to find any input that produces it, which remains impractical against MD5. Almost every real MD5 weakness is a collision attack, not a preimage attack.

Can I trust the checksum posted next to a download?

Only as far as you trust the page it is on. If whoever controls the download can also edit the checksum beside it, a match just confirms the file matches itself — true of MD5, SHA-256 or anything else. Real verification needs a signature or a checksum delivered through a separate, trusted channel.

Should I switch from MD5 to SHA-256 everywhere?

For anything where someone might want to tamper with the input — signatures, certificates, security tokens — yes, and there is essentially no cost to it on modern hardware. For non-adversarial jobs like deduplicating trusted files or spotting a truncated download, MD5 still works and switching buys nothing.

What made the 2008 MD5 attack different from the 2004 one?

The 2004 collision produced two meaningless blobs built to match each other. The 2008 chosen-prefix technique let attackers start from two documents they actually wanted, including a real certificate authority signing request, and pad each one so it shared an MD5 digest with the other — which is what let them forge a rogue certificate authority trusted by ordinary browsers.

Last updated September 24, 2026