MD5 vs SHA-256: Which Hash to Use (and Never for Passwords)

MD5 vs SHA-256 in one line: MD5 is broken, because anyone can deliberately create two different files with the same MD5 hash; SHA-256 has no known practical attack of that kind, so use it for checksums, signatures and anything security-related. Neither is right for storing passwords; that needs a deliberately slow algorithm like Argon2id or bcrypt. You can see both side by side in the free hash generator, which works out MD5, SHA-1, SHA-256, SHA-384 and SHA-512 as you type.

The same input, two fingerprints

Type hello into the hash generator:

MD5      5d41402abc4b2a76b9719d911017c592
SHA-256  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Now type Hello with a capital H:

MD5      8b1a9953c4611296a827abf8c47804d7
SHA-256  185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

One changed letter, and every hash changes completely. That's the "avalanche effect" every good hash has. Both functions are also one-way: you can't work backwards from the hash to the input. The difference is in how well they resist people who are actively trying to cheat them.

MD5 vs SHA-256 side by side

	MD5	SHA-256
Output size	128 bits (32 hex characters)	256 bits (64 hex characters)
Family	Designed in the early 1990s	SHA-2, standardised by NIST in the early 2000s
Collision attacks	Practical; collisions can be made on an ordinary computer	None known in practice
Safe for signatures and certificates	No	Yes
Fine for spotting accidental corruption	Yes	Yes
Speed	Fast	Fast (sometimes slightly slower, sometimes faster, depending on the chip)
Good for storing passwords	No	No

SHA-1 (160 bits, 40 hex characters) sits in between. It was the standard for years, but researchers published a practical collision in 2017, so it's retired for security use too.

What "broken" means for MD5

A hash needs three properties to be secure:

1. Pre-image resistance: given a hash, you can't find an input that produces it.
2. Second pre-image resistance: given a file, you can't find a different file with the same hash.
3. Collision resistance: you can't find any two different inputs with the same hash.

MD5 has failed the third badly. Since the mid-2000s, researchers have been able to generate pairs of different files with identical MD5 hashes, and the technique was later used in a real attack to forge a code-signing certificate. That means an attacker could prepare a harmless file and a malicious one with the same MD5, get the harmless one approved, then swap it. For anything where trust depends on the hash, MD5 is out.

MD5 is still fine for non-security jobs: spotting a corrupted copy, de-duplicating files you created yourself, or as a cache key. Nobody is attacking those.

Checksums: use SHA-256

When you publish a download, list its SHA-256. When you verify one, compare SHA-256 if it's offered. Many projects still list MD5 alongside it for old tools; that's fine for catching a broken download, but an MD5 match means little if an attacker could have prepared the file, because they can build a harmless and a harmful file that share one MD5. A SHA-256 (or SHA-512) match still holds up in that case. No hash helps if the attacker also controls the page listing it; that's what signed checksums are for. Our step-by-step guide shows how to verify a file checksum, in the browser or with built-in commands.

Passwords: neither

This is where many tutorials go wrong. MD5 and SHA-256 are both designed to be fast, and fast is exactly what you don't want for passwords. If a database of password hashes leaks, attackers guess passwords, hash each guess and look for matches. With a fast hash and modern graphics cards, that can mean billions of guesses per second, and common passwords fall in moments. A plain SHA-256 of a password is only a little better than MD5 for this purpose.

Password storage needs a slow, salted algorithm built for it. As per the OWASP Password Storage Cheat Sheet (check the current version for exact settings), the recommended order is:

• Argon2id (first choice), with at least 19 MiB of memory and 2 iterations.
• scrypt, if Argon2id isn't available.
• bcrypt, for older systems, with a work factor of 10 or more (it only uses the first 72 bytes of a password).
• PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations, where FIPS-140 compliance is required.

Each adds a random salt per password, so two users with the same password get different hashes, and pre-computed tables are useless. Use your framework's built-in password hashing rather than writing your own.

As a user, the best defence is a long, unique password for every site; the free password generator makes them. Our guide on creating a strong password covers the habits.

Hashing is not encryption (or encoding)

Three words often get mixed up:

• Hashing (MD5, SHA-256): one-way. Same input, same fingerprint. No way back.
• Encryption (AES, RSA): two-way, with a key. Built to keep data secret.
• Encoding (Base64): two-way, no key. Just a format change; see what is Base64.

"Decrypting" an MD5 hash isn't possible. Websites that claim to do it are looking hashes up in huge tables of common inputs, which is another reason short or common inputs make poor secrets.

Which should you use?

Job	Use
Verifying downloads, publishing checksums	SHA-256 (or SHA-512)
Digital signatures, certificates, Git-style content IDs in new systems	SHA-256 or stronger
Detecting accidental corruption in your own files	Any; MD5 is fine
Storing user passwords	Argon2id, scrypt, bcrypt or PBKDF2, never a plain hash
Hiding data	Encryption, not hashing

Compare them yourself

Type or drop a file into the free hash generator to see MD5, SHA-1, SHA-256, SHA-384 and SHA-512 together, and paste an expected value to check for a match. It works on your device; nothing is uploaded.