MD5 vs SHA-256: Which Should You Use?

MD5 and SHA-256 are both hash functions — they take any input and produce a fixed-length fingerprint of it. They look similar, they are used in similar places, and one of them is thoroughly broken. Knowing which, and why, is one of those pieces of knowledge that separates people who use cryptography correctly from people who use it as decoration.

What a hash function actually is

Feed a hash function any data — a word, a document, a 10 GB video — and it returns a fixed-size string called the hash or digest. MD5 always returns 128 bits (32 hex characters); SHA-256 always returns 256 bits (64 hex characters).

Good hash functions have three properties that make them useful:

• Deterministic. The same input always produces the same hash. Every time, forever.
• One-way. Given a hash, you cannot reverse it to recover the input. This is not encryption — there is no key and no way back. Information is genuinely destroyed.
• Avalanche effect.Change a single bit of the input and roughly half the output bits flip. The hash of “hello” and “hellp” share no visible resemblance.

That last property is what makes hashes useful for detecting tampering: any change at all, however tiny, produces a completely different fingerprint.

What went wrong with MD5

MD5 dates from 1991 and was the workhorse of its era. It is fast — and that speed, along with a structural weakness, is what killed it.

The fatal flaw is collisions. A collision is when two different inputs produce the same hash. Collisions must exist mathematically for any hash function — you are squeezing infinite possible inputs into a finite number of outputs — but a secure hash makes finding one computationally infeasible.

MD5 does not. Since 2004, researchers have been able to construct MD5 collisions deliberately, and today it can be done on an ordinary laptop in seconds. Someone can craft two different files with identical MD5 hashes.

Why a collision is genuinely dangerous

It is worth making this concrete, because “collision” sounds abstract and harmless.

Suppose a security team reviews a piece of software and publishes its MD5 hash so users can verify they downloaded the authentic version. With a collision attack, an attacker can produce two files: a harmless one that passes review, and a malicious one — both with the same MD5 hash. The harmless file gets approved; the malicious file gets shipped; the hash check passes perfectly.

This is not theoretical. Collision attacks on MD5 have been used in real malware, most famously to forge certificates. Any MD5 hash used to prove that something has not been tampered with is providing false comfort.

SHA-256

SHA-256 is part of the SHA-2 family, published in 2001, and it remains cryptographically secure. Despite two decades of intense scrutiny, no practical collision attack exists. It underpins TLS certificates, Bitcoin, code signing, and essentially all modern integrity checking.

Its larger 256-bit output also makes brute-force search hopeless: the number of possible hashes is around 10⁷⁷, comparable to the number of atoms in the observable universe. You are not enumerating that.

Head to head

• Output size: MD5 = 128 bits (32 hex chars) · SHA-256 = 256 bits (64 hex chars)
• Speed: MD5 is faster — which is a disadvantage in security contexts, because it also speeds up the attacker
• Collision resistance: MD5 = broken · SHA-256 = secure
• Safe for security use: MD5 = no · SHA-256 = yes

So is MD5 completely useless?

No — and this nuance matters. MD5 is broken for security, not for accident detection.

The distinction is whether there is an adversary. MD5 collisions must be deliberately engineered; they do not happen by chance. So MD5 is still perfectly adequate for:

• Checking a file downloaded correctly — verifying against random corruption, not against a malicious actor.
• Finding duplicate files on your own disk.
• Cache keys and hash-table lookups, where speed matters and security does not.

The rule of thumb: if an attacker could benefit from a collision, do not use MD5. If you are only guarding against noise and mistakes, it is fine — and faster.

The trap: neither is right for passwords

This is the most important practical point in the article, and it is widely got wrong.

You might reason: hashes are one-way, so hashing passwords with SHA-256 keeps them safe. But SHA-256 is the wrong tool for passwords, precisely because it is fast.

Modern hardware can compute billions of SHA-256 hashes per second. If an attacker steals your database of SHA-256 password hashes, they simply hash every candidate password until they find matches. Speed, which is a virtue for checksums, is a catastrophe here — it is a gift to the attacker.

Passwords need deliberately slow, memory-hard algorithms designed for the job: bcrypt, scrypt or Argon2. They are engineered to be expensive to compute, and they include a salt — random data added to each password so that identical passwords produce different hashes, defeating precomputed lookup tables.

If you are building anything that stores passwords: not MD5, not SHA-256. Use Argon2 or bcrypt.

Frequently asked questions

Can you reverse a hash? No. But for a weak input you can guess it — hash billions of candidates and compare. That is why short or common passwords fall instantly regardless of the algorithm.

Is SHA-1 safe? No. It was broken by a practical collision in 2017 and should be treated like MD5 — retired from security use.

Should I use SHA-512 instead of SHA-256? SHA-512 is also secure and is faster on 64-bit hardware. SHA-256 is sufficient for essentially all purposes.

Why do downloads still publish MD5 checksums? Largely inertia. Reputable projects have moved to SHA-256 for anything security-relevant.

Generate a hash now

Use our Hash Generator to compute MD5, SHA-1, SHA-256, SHA-384 and SHA-512 hashes in your browser — nothing is uploaded. For choosing a strong password, read how to create a strong password or use the Password Generator.