MD5 vs SHA256: Key Differences and Which to Use

Both MD5 and SHA-256 take an input of any size and return a fixed-size digest — that much they share with every hash function, and it's covered in general in the Hash Generator guide. The question that actually decides which one to reach for is narrower than “which is better”: can an attacker construct two different inputs that hash to the same digest? For MD5, yes — reliably, cheaply, and since the mid-2000s. For SHA-256, no practical method to do that exists today. That single fact, not digest length or speed, is what determines whether MD5 is safe to use in a given context.

Everything else in this article follows from that one distinction: is MD5 secure enough for what you're about to use it for, or does the context involve an adversary who benefits from a forged match.

Hashing the same input with both algorithms makes the size difference concrete. These are the standard NIST test vectors for the three-byte input "abc", reproducible with any correct implementation:

MD5     (128-bit / 32 hex chars)
900150983cd24fb0d6963f7d28e17f72

SHA-256 (256-bit / 64 hex chars)
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

“Broken” gets thrown around loosely enough that it's worth being precise about what actually happened. In 2004, researchers published the first practical MD5 collision — two distinct inputs producing the same 128-bit digest, found using techniques far faster than brute force. By 2005, the attack had been refined to the point of producing two different X.509 certificates with valid-looking but colliding hashes, and by 2008 a team demonstrated a rogue certificate authority certificate that exploited exactly this weakness. This is not a hypothetical weakened bound on security — it's a constructive attack: give the algorithm two chosen documents, and it can be made to produce identical digests for both.

The real-world consequence arrived with Flame, malware discovered in 2012 that forged a Microsoft digital certificate by exploiting an MD5 collision, allowing it to sign malicious code so that it appeared to come from a trusted Microsoft source. That single incident is why MD5 is unacceptable anywhere collision resistance matters: digital signatures, TLS/SSL certificates, and software supply-chain verification all rely on the assumption that nobody can quietly swap in a different document with the same hash. SHA-256 has no equivalent demonstrated attack — it belongs to the SHA-2 family, and as of today, constructing a collision for it is computationally out of reach, which is exactly why it's the standard choice behind modern TLS certificates and Bitcoin's proof-of-work.

The collision history above answers “is MD5 secure” with a clear no for adversarial contexts, but it doesn't make MD5 useless everywhere, and treating it that way overcorrects past the actual threat model. Collisions are a problem specifically when someone might benefit from constructing two different inputs that hash the same — that requires an adversary with a motive. A lot of hashing has no adversary at all.

• Deduplication.Hashing file contents to check whether two files are probably identical doesn't involve anyone trying to forge a match — a coincidental collision is astronomically unlikely, and nobody is incentivized to engineer one on purpose.
• Checksums for accidental corruption.Verifying that a download wasn't truncated by a flaky connection or corrupted by a bad mirror is a check against randomness, not against an adversary deliberately constructing a colliding file.
• Legacy systems with real migration cost.A system built on MD5 checksums for internal, non-adversarial integrity checks doesn't automatically need an emergency rewrite — the question is whether the actual threat model involves someone motivated to construct a collision, not whether MD5 has a bad reputation.

The practical rule for which hash algorithm to use: if the hash is meant to prove something to an adversary — that a certificate is genuine, that a signature wasn't forged, that a file wasn't swapped by someone with an incentive to swap it — use SHA-256 or better. If the hash is only meant to detect accidental change or find identical files with nobody trying to fool the check, MD5's known weakness is irrelevant to that job.

MD5 is genuinely faster to compute than SHA-256: it operates on a smaller 128-bit internal state and runs fewer rounds of mixing per block, so hashing the same data costs less CPU time with MD5. That speed advantage is real and is part of why MD5 checksums are still common in non-adversarial pipelines processing large volumes of data — the extra cost of SHA-256 is negligible per file but adds up at scale.

That speed advantage becomes a liability in exactly one context: password storage. A fast, deterministic hash is precisely what makes brute-forcing a leaked password database practical — an attacker with a stolen table of digests can try billions of candidate passwords per second against a fast hash, MD5 or SHA-256 alike. Neither algorithm was designed to be slow, and password storage specifically needs deliberate slowness plus per-user salting, which is why bcrypt, scrypt, and Argon2 exist as a separate category of tool. Comparing MD5 vs SHA-256 speed is a meaningful question for checksums and deduplication; it's the wrong question entirely for passwords.

GenKitLab's Hash Generator computes SHA-256, SHA-1, SHA-384, SHA-512, and HMAC digests of text or a file entirely in your browser using the WebCrypto API, so nothing you paste or upload is sent anywhere. For a deeper look at what a cryptographic hash actually guarantees, HMAC-based authenticity checks, and verifying file integrity after a download, see the Hash Generator guide.