Is MD5 safe?
Why MD5 is broken, why that does not make it useless, and what to use for passwords instead.
The short answer: it depends entirely on what you are using it for. MD5 is genuinely broken for anything security-related, and genuinely fine for some everyday jobs. Blanket advice in either direction is wrong, so it is worth understanding which situation you are in.
What a hash actually is
A hash function takes any input — a word, a file, a whole database — and produces a fixed-length string. The same input always gives the same output. abc is always 900150983cd24fb0d6963f7d28e17f72 in MD5, whether you compute it today or in ten years.
The critical property is that it only runs one way. You cannot take the hash and work backwards to the original. There is no decryption key, because nothing was encrypted. The input is not “in there” — it has been shredded into a fingerprint of a fixed size, and most of the information is gone.
Then why do “MD5 decrypter” sites work?
They are not reversing anything. They are lookup tables.
Someone hashed every common password, every dictionary word, and every short string, and stored the results in a database. When you paste a hash, the site checks whether it has seen that hash before. If your input was password123, it is in the table and comes back instantly. If your input was a long random string nobody has ever hashed, the site finds nothing.
These are called rainbow tables, and the important thing to notice is that they defeat weak inputs, not the algorithm. A rainbow table works just as well against SHA-256. Switching algorithm does not save a password of 123456.
What “MD5 is broken” actually means
The specific failure is collision resistance. A collision is two different inputs that produce the same hash. For MD5, collisions can be constructed deliberately, cheaply, on ordinary hardware. Attackers can craft two files — say a harmless document and a malicious one — that share a digest.
SHA-1 has fallen the same way. A real collision was demonstrated publicly, and the cost of producing one has only dropped since.
Notably, this is not the same as MD5 being reversible. There is still no practical way to take an arbitrary MD5 hash and recover its input. The break is that an attacker who controls the input can manufacture matches.
That distinction decides everything below.
What MD5 is still fine for
If nobody is attacking you, collision resistance does not matter. MD5 is fast, short, and perfectly adequate for:
- Detecting accidental corruption. A file damaged in transfer will not coincidentally produce the same digest.
- Deduplication. Spotting that two uploads are the same file.
- Cache keys. Turning a long input into a short, stable identifier.
The condition is that the input comes from your own system rather than from someone who might benefit from forging a match. The moment an adversary can choose the input, MD5 stops being appropriate.
Where MD5 and SHA-1 must not be used
- Verifying that a download has not been tampered with
- Digital signatures and certificates
- Any integrity check where someone gains from the file being swapped
- Anything a security auditor will look at
Use SHA-256 for these. It is available everywhere, it is fast enough, and it has no known practical break.
Passwords: not MD5, and not plain SHA-256 either
This is the part that matters most, and the part most often got wrong.
Never store passwords hashed with MD5, SHA-1, or SHA-256. The problem with the SHA family here is not that it is weak — it is that it is fast, and speed is precisely what an attacker with a stolen database wants. Modern hardware computes billions of SHA-256 hashes per second. A fast hash lets an attacker try the entire dictionary against every stolen record in a short time.
Password storage needs a function that is deliberately slow and salted (a unique random value per password, so identical passwords do not produce identical hashes and one rainbow table cannot cover them all):
- Argon2id — the current first choice
- scrypt — a solid alternative
- bcrypt — older, still respectable, still widely deployed
All three let you tune the cost, so you can make each guess expensive enough to make bulk cracking impractical while a single legitimate login stays imperceptible.
If you are building password storage yourself, use a well-maintained library rather than assembling this from primitives.
Which algorithm for which job
| What you are doing | Use |
|---|---|
| Checking a file survived a transfer | MD5 or SHA-256 — either works |
| Verifying a download against a publisher’s hash | SHA-256 |
| Deduplication, cache keys | MD5 is fine and fast |
| Digital signatures, certificates | SHA-256 or stronger |
| Storing passwords | Argon2id, scrypt or bcrypt — never a plain hash |
| Comparing two strings for equality | Just compare the strings |
The pattern across the table: the more an attacker stands to gain from forging a match, the stronger the algorithm has to be. Where nobody is attacking you, speed is the only thing that matters and MD5 still wins.
Computing a hash without uploading it
Toolora’s hash generator runs entirely in your browser. It shows MD5, SHA-1, SHA-256, SHA-384 and SHA-512 side by side, with MD5 and SHA-1 marked as unsuitable for security use.
That matters here more than on most tools: people paste sensitive strings into hash generators. Nothing you type is sent anywhere, because there is no server involved — you can disconnect from the internet after the page loads and it still works.
If you are also wondering whether Base64 protects anything, it does not — that guide explains why encoding and hashing are different things again.