MD5 vs SHA-256: Differences, Collisions and When to Use Each

In MD5 vs SHA-256, the key difference is security. Both turn any data into a fixed-length fingerprint, but MD5 is broken: attackers can create two different files with the same MD5 hash. SHA-256 has no known practical collision attack. Use SHA-256 for checksums and integrity checks, MD5 only for spotting accidental corruption, and neither for passwords.

Hashes are everywhere on the web, often without anyone noticing: download checksums, TLS certificates, email signatures, API webhooks and login systems all depend on them. Picking the wrong algorithm, or the right algorithm for the wrong job, is a common source of security weaknesses. This guide explains what each hash does, why MD5 fell, and what to use instead for passwords and message signing.

To try any of this yourself, our free hash generator creates MD5, SHA-1, SHA-256, SHA-384 and SHA-512 hashes of text or files in your browser, makes HMAC signatures, and compares a file against a published checksum. Nothing is uploaded.

What a hash function does

A cryptographic hash function takes input of any size and produces a fixed-size output, called a hash or digest. Good hash functions have three properties:

1. Deterministic. The same input always gives the same hash.
2. One-way (preimage resistance). Given a hash, you can't work backwards to the input.
3. Collision resistant. It's infeasible to find two different inputs with the same hash.

Change a single character and the hash changes completely:

SHA-256("Make It Flow") and SHA-256("Make it Flow") share no visible pattern.

A hash is not encryption. There's no key and nothing to decrypt. It's also not encoding: Base64 can be reversed by anyone, while a hash can't. Our guide to what Base64 encoding is explains that difference in more detail.

MD5 vs SHA-256 compared

Example output

Input:   hello
MD5:     5d41402abc4b2a76b9719d911017c592
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Why MD5 is broken: collisions explained

A collision is two different inputs that produce the same hash. Every hash function has collisions in theory, because there are infinitely many inputs and a fixed number of outputs. What matters is whether anyone can find one on purpose.

For MD5, they can. RFC 6151, published by the IETF in 2011, states that "MD5 is no longer acceptable where collision resistance is required such as digital signatures". It cites published attacks that find a collision in about a minute on a standard notebook PC. Hardware has only got faster since.

Why does that matter? Imagine an attacker prepares two documents, an innocent one and a malicious one, with the same MD5 hash. If someone signs or approves the hash of the innocent version, the signature is equally valid for the malicious one. The same trick has been used against certificate systems, which is why MD5-signed certificates are no longer trusted by browsers.

What about preimage attacks?

Collision attacks let an attacker create two matching inputs of their choosing. A preimage attack would let them find an input matching a hash someone else made, which is much harder. No practical preimage attack on MD5 is publicly known. That's not a reason to keep using it for security: once collision resistance fails, an algorithm is generally treated as unsuitable for any new security design.

And SHA-1?

SHA-1 sits between the two. Its 160-bit output was once the standard, but researchers from Google and CWI Amsterdam announced the first practical SHA-1 collision, two different PDFs with the same hash, in February 2017. NIST had already disallowed SHA-1 for digital signatures, and in December 2022 it announced SHA-1 should be phased out by 31 December 2030 in favour of SHA-2 and SHA-3. Don't choose SHA-1 for anything new.

When MD5 is still acceptable

MD5 is fine where nobody is trying to fool you and you only need to detect accidental changes:

• Spotting corruption after copying a large file between drives or over a flaky connection.
• De-duplicating files in a photo library or backup, where a false match would be an inconvenience rather than a security problem.
• Cache keys and ETags, where the hash is just a quick identifier for content.
• Legacy systems that only publish MD5 checksums. Checking them is better than nothing, but ask the publisher for SHA-256.

If there's any chance someone could deliberately substitute a file, use SHA-256.

Using SHA-256 for file checksums

Software publishers often list a SHA-256 checksum next to a download. Comparing it confirms the file you received is byte-for-byte identical to the one they published.

How to check a checksum

Compare the whole string, not just the first and last few characters.

What a checksum does and doesn't prove

A matching checksum proves the file wasn't corrupted in transit and matches what's on the publisher's page. It doesn't prove the publisher is trustworthy. If an attacker compromises the website, they can replace both the file and the checksum. That's why serious projects also sign releases with a digital signature, and why the page itself should be served over valid HTTPS. You can confirm a site's certificate with our SSL checker.

Why neither MD5 nor SHA-256 should store passwords

This is the mistake that causes real damage. MD5 and SHA-256 are designed to be fast, and fast is exactly what you don't want for passwords. If a database of password hashes leaks, attackers run billions of guesses against it on graphics cards. A fast hash lets them test common passwords and leaked password lists very quickly.

The OWASP Password Storage Cheat Sheet recommends slow, salted, tunable password hashing algorithms instead:

You rarely need to implement these yourself. PHP's password_hash(), Django, Laravel, Rails and ASP.NET Identity all use an appropriate algorithm with a random salt by default. The rule is simple: if you see md5($password) or sha256($password) in a codebase, treat it as a vulnerability to fix.

If you inherit a site that uses fast hashes, you don't need everyone to reset at once. A common approach is to rehash each user's password with Argon2id or bcrypt the next time they log in successfully, and to force a reset for accounts that haven't logged in after a set period.

Storage is only half the story. Long, unique passwords and two-factor authentication matter just as much. Our strong password guide and a password generator help with the user side, and two-factor authentication for website admins covers the rest.

HMAC: proving a message came from you

Sometimes you need more than integrity. A webhook receiver needs to know a message really came from the sender and wasn't altered. That requires a shared secret key, and the correct tool is HMAC (hash-based message authentication code), defined in RFC 2104.

It's tempting to do SHA-256(secret + message). Don't. MD5, SHA-1 and SHA-256 are all vulnerable to length extension attacks, where someone who knows the hash of secret + message can compute a valid hash for secret + message + extra data without knowing the secret. HMAC's construction prevents this.

In practice:

• Use HMAC-SHA256 for webhook signatures, signed URLs and API request signing. Many providers, including Stripe and GitHub, sign webhooks this way.
• Compare signatures in constant time, using functions such as hash_equals() in PHP or crypto.timingSafeEqual() in Node.js, so attackers can't learn the correct value from response timing.
• Avoid HMAC-MD5 in new designs. RFC 6151 says removing it from existing protocols isn't urgent, but new protocols shouldn't use it.

JSON Web Tokens signed with HS256 use exactly this: HMAC with SHA-256. Our explainer on what a JWT is covers how that signature works, and a JWT decoder shows the algorithm in any token's header.

Where you'll meet SHA-256 on your own website

• TLS certificates. Modern certificates are signed with SHA-256 or stronger.
• Email authentication. DKIM signatures use rsa-sha256, and RFC 8301 says signers must not use the older SHA-1 variant. Our guide to what DKIM is explains how the signature is checked.
• Subresource Integrity. The integrity attribute on scripts and stylesheets loaded from a CDN accepts SHA-256, SHA-384 or SHA-512 hashes, so the browser refuses a file that's been changed.
• Content Security Policy. CSP can allow specific inline scripts by their SHA-256 hash. The hash goes in the script-src directive.

Quick decision guide

1. Checking a download or backup for tampering? SHA-256.
2. Only spotting accidental corruption on your own files? MD5 works, SHA-256 is better.
3. Storing passwords? Argon2id, or bcrypt in older stacks. Never MD5 or plain SHA-256.
4. Signing webhooks or API requests with a shared secret? HMAC-SHA256.
5. Digital signatures or certificates? SHA-256 or stronger, via a proper signing library.
6. Inherited system using MD5 or SHA-1 for security? Plan a migration.

If your business handles customer logins or payment webhooks and you're unsure what's under the hood, a short code review is worth it. Make It Flow's free security headers checker is a quick first look at the public side of your site.

FAQ

Is SHA-256 more secure than MD5?

Yes. SHA-256 produces a longer 256-bit hash and has no known practical collision attack, while MD5 collisions can be created in minutes on ordinary hardware. For anything involving security, such as signatures, certificates or tamper-proof checksums, SHA-256 is the right choice. MD5 is only suitable for detecting accidental corruption.

Can MD5 be decrypted?

No, because hashing isn't encryption and there's no key. However, short or common inputs can be found by looking the hash up in precomputed tables or by guessing very quickly. That's why an unsalted MD5 hash of a password offers almost no protection: "decrypting" it really means guessing the password and checking.

Should I use SHA-256 to hash passwords?

Not on its own. SHA-256 is designed to be fast, so attackers can test enormous numbers of guesses against a leaked hash. Use a dedicated password hashing algorithm such as Argon2id, scrypt or bcrypt, which are deliberately slow and salted. Most modern frameworks do this by default through functions like password_hash().

Is MD5 still safe for file checksums?

For catching accidental corruption, such as a bad copy or an interrupted download, yes. For protecting against deliberate tampering, no, because an attacker can craft a malicious file with the same MD5 hash as a legitimate one. If the publisher offers a SHA-256 checksum, use that instead.

What is the difference between a hash and HMAC?

A hash fingerprints data so you can detect any change, but anyone can compute it. HMAC combines a hash with a secret key, so only someone who knows the key can produce a valid signature. Use HMAC-SHA256 when you need to prove a message came from a trusted sender, such as a webhook.

Is SHA-256 quantum safe?

SHA-256 is considered far more resilient to quantum computing than public-key algorithms like RSA. Known quantum search techniques would weaken hash functions but not break them in the same way. Organisations wanting extra margin sometimes choose SHA-384 or SHA-512. The bigger post-quantum changes affect encryption and signatures, not hashing.