Most searches for MD5 vs. SHA-256 are really three questions wearing one coat. You might be checking that a download arrived intact, or verifying something an attacker would like to tamper with, or storing user passwords. Those are three different jobs with three different answers — and for one of them, both MD5 and SHA-256 are the wrong tool.
Here is what separates them, what people mean when they say MD5 is broken, and the one correction that matters more than the rest.
MD5 vs. SHA-256: three jobs, three answers
Both are cryptographic hash functions: feed in any amount of data, get back a fixed-length fingerprint, and change one bit of the input and the whole output changes. Where they part company is how hard it is to deliberately produce two different inputs with the same fingerprint — a collision.
That distinction only matters if there is a someone. So sort your problem first:
- Integrity against accidents — did this file copy without corruption? MD5 still does this job, and so does SHA-256.
- Integrity against people — signatures, certificates, anything where the input comes from someone who benefits from fooling you. MD5 is broken here.
- Password storage — neither one. This needs a hash function that is deliberately slow, which is the opposite of what MD5 and SHA-256 are for.
Checksums: MD5 is weak, not useless
A corrupted download is not adversarial. A flipped bit or a truncated transfer is not trying to land on a particular hash value, and the odds of random damage producing a matching 128-bit digest are negligible. That is why RFC 6151, the March 2011 IETF document that catalogues MD5 attacks, still carves out this case: "Where the MD5 checksum is used inline with the protocol solely to protect against errors, an MD5 checksum is still an acceptable use."
The catch is the threat model, not the maths. If someone could have swapped the file on the mirror, they could have published a matching MD5 beside it, and the checksum proves nothing about who wrote it. Since computing either digest is the same click in a hash generator, taking the SHA-256 line when it is offered costs nothing.
Where MD5 is genuinely broken
The collapse is well documented and it is old. Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu published actual MD5 collisions in a paper submitted to the IACR ePrint archive on 16 August 2004, and the attacks got cheap fast. RFC 6151 records that by 2006 a collision took "about one minute on a standard notebook PC", and that a 2007 result claimed "10 seconds or less on a 2.6Ghz Pentium4".
Then it left the lab. In December 2008 a research team used a chosen-prefix collision to create a rogue certificate authority certificate. In 2012 the Flame malware forged a Microsoft code-signing certificate the same way; Microsoft’s write-up of 6 June 2012 confirms the certificate’s signature algorithm was md5RSA and calls the technique a chosen prefix collision attack. CERT/CC note VU#836068 has said since 2008 that MD5 is cryptographically broken and unsuitable for further use.
SHA-1 is on the same road, a few years behind. CWI Amsterdam and Google announced the first practical SHA-1 collision on 23 February 2017 — two different PDFs with one SHA-1 value. NIST now disallows SHA-1 for generating digital signatures and other collision-resistance applications, and after 31 December 2030 any FIPS 140 validated module listing SHA-1 moves to the historical list. MD5 never had that status to lose: it is not in FIPS 180-4, the Secure Hash Standard, at all.
Passwords: both answers are wrong
This is the correction worth more than everything above. If you are storing passwords, the problem with MD5 is not that it is broken — it is that it is fast, and so is SHA-256. Speed is exactly what an attacker holding a stolen database wants. The OWASP Password Storage Cheat Sheet puts it directly: "Fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly."
What you want instead is a purpose-built password hashing scheme with a tunable cost. OWASP’s order of preference, as of this writing:
- Argon2id first, with a stated minimum of 19 MiB of memory, an iteration count of 2 and 1 degree of parallelism.
- scrypt if Argon2id is not available.
- bcrypt for legacy systems, with a work factor of 10 or more, noting its 72-byte password limit.
- PBKDF2 where FIPS-140 compliance is required, with 600,000 or more iterations using HMAC-SHA-256.
Every one of those takes a salt — a unique random value per user. NIST Special Publication 800-63B revision 4, published 26 August 2025, requires that passwords "SHALL be salted and hashed using a suitable password hashing scheme" and that the salt "SHALL be at least 32 bits in length". The salt is what stops one precomputed table cracking every account at once: it "protects against an attacker’s pre-computing hashes using rainbow tables or database-based lookups", in OWASP’s words. None of it helps if the password is guessable, which is a separate problem — see Are Online Password Generators Safe? How Client-Side Generation Works.
Output length, and the speed question
Hex notation packs four bits into each character, so the digest length in hex characters is always the bit length divided by four:
| Algorithm | Digest size | Hex characters | NIST status |
|---|---|---|---|
| MD5 | 128 bits | 32 | Not an approved hash function |
| SHA-1 | 160 bits | 40 | Disallowed for signatures; retired after 2030 |
| SHA-256 | 256 bits | 64 | Approved |
| SHA-512 | 512 bits | 128 | Approved |
On speed: MD5 is the simpler, older design and is generally quicker per byte in plain software. That gap is narrower than it sounds on current hardware, though. Intel’s SHA Extensions add dedicated instructions for SHA-1 and SHA-256 — sha256rnds2, sha256msg1 and sha256msg2 — with no equivalent for MD5, because nobody builds silicon for a broken hash. For the file sizes most people hash, the difference decides nothing. And in the one case where hashing speed is counted in billions of operations — password cracking — being fast is the flaw.
Why you cannot decrypt a hash
Hashing is not encryption and there is nothing to reverse. Encryption takes a key and gives the plaintext back. A hash takes no key and throws information away: a 500 MB video and an empty file both come out of MD5 as 32 hex characters. Most of the input is simply gone. NIST defines a hash function as one-way — computationally infeasible to find an input that maps to a given output. OWASP says it plainer: "hashing is a one-way function (i.e., it is impossible to ‘decrypt’ a hash and obtain the original plaintext value)".
So what are the sites advertising an "MD5 decrypter"? They are search engines, not decrypters. They hash enormous lists of candidate strings in advance and look your digest up in the results. If your input was password123 they find it instantly; if it was 40 bytes of randomness, they never will, because it was never in the list. Rainbow tables are a space-saving version of the same trick, storing chains of hashes rather than every value, but they still search the input space rather than undo the maths. It is the same category error as assuming Base64 is encryption.
What to actually use
- Verifying a download, no adversary in the picture — either works. Use whichever digest the project publishes; prefer SHA-256 if both are offered.
- Anything signed, certified, or supplied by a third party — SHA-256 or stronger. Not MD5, not SHA-1.
- Passwords — Argon2id, scrypt or bcrypt, salted, with the cost factor as high as your login latency tolerates. Never a bare MD5 or SHA-256.
- Non-security uses — cache keys, shard selection, change detection on content you control. MD5 is fine, provided nobody gains from forcing a collision.
One honest caveat: recommended password parameters get revised as hardware gets faster, and this page is a snapshot. If the choice carries real consequences, read the current OWASP Password Storage Cheat Sheet and NIST SP 800-63B yourself. The hash generator here is for spot checks and learning what the output looks like, not a security review.
MD5, SHA-1, SHA-256 and SHA-512 — computed in your browser, nothing uploaded.
Open Hash Generator →Frequently asked questions
Not for anything adversarial. Practical MD5 collisions were demonstrated in 2004 and were down to seconds on ordinary hardware by 2007, and the technique has been used in the wild to forge certificates. CERT/CC describes MD5 as cryptographically broken and unsuitable for further use. It is not a NIST-approved hash function.
For detecting accidental corruption, yes. RFC 6151 states that where an MD5 checksum is used solely to protect against errors, it is still an acceptable use. It is not safe if someone may have deliberately replaced the file, because they could supply a matching MD5 as well. Prefer SHA-256 when the project publishes one.
Neither. Both are fast general-purpose hashes, and speed is what makes offline cracking cheap. OWASP recommends Argon2id, then scrypt, then bcrypt for legacy systems, or PBKDF2 with HMAC-SHA-256 where FIPS-140 compliance is required — always with a per-user salt of at least 32 bits.
MD5 produces a 128-bit digest, which is 32 characters in hexadecimal. SHA-256 produces a 256-bit digest, which is 64 hex characters. Hex stores four bits per character, so the character count is always the bit length divided by four.