MD5 has outlived its own funeral by twenty years: broken beyond repair for security, still quietly doing checksum work in ETags, mirrors and migration scripts. What the 1992 hash still does honestly, how the "decrypt MD5" sites actually operate, and the salting lesson its downfall taught.
Where MD5 stands
MD5, from RFC 1321, produces a 128-bit digest, 32 hex characters. Its collision resistance did not erode, it collapsed: since Wang and Yu's 2004 paper, generating two inputs with the same MD5 has gone from research result to a sub-second job for the fastcoll tool. Preimage resistance (given a hash, find an input) technically stands at 2^123, so nobody reverses an MD5 of random data, but for any use where an attacker supplies content, the function is simply gone.
Browsers took a side: the Web Crypto API refuses to implement MD5 at all. This page ships its own implementation of the RFC instead, about forty lines of the original algorithm, because the legitimate legacy uses did not disappear just because the algorithm did from the platform.
How to use this generator
- Hash text: type or paste; the 32-character digest updates live, input read as UTF-8, matching
md5sumand every mainstream library. - Hash a file: drop it on the input pane. Raw bytes are hashed, and the download button writes an
md5sum-compatible checksum file. - Verify: paste the expected checksum; mismatches name the first differing character, and a 40- or 64-character paste is called out as the SHA-1 or SHA-256 it actually is.
The commonest text-hashing surprise is worth repeating here: a trailing newline changes everything. echo text | md5sum and this page will disagree, because echo appends \n; printf '%s' text | md5sum agrees.
How "MD5 decrypters" work
Search for any MD5 hash and sites will offer to "decrypt" it. There is no decryption anywhere in that pipeline: the sites hold databases of hashes precomputed from leaked passwords, dictionaries and every string up to some length, and they look yours up. The scale is real (the larger services claim tens of billions of entries), the mechanism is a phone book read backwards.
This is the attack that made salting a requirement. A salt, a few random bytes mixed into each password before hashing and stored alongside the result, makes every user's hash unique even for identical passwords, and it makes precomputed tables worthless, because the table would have to exist per salt. The lookup sites are living proof of what unsalted storage costs: every historical breach of unsalted MD5 password tables fed exactly these databases. Salting, and why it still is not enough without a slow hash, is demonstrated live on the bcrypt generator.
Where MD5 still lives
The survivors are the uses with no adversary in the threat model. Amazon S3 ETags are the MD5 of the object for single-part uploads, and a decade of tooling checks uploads that way. Linux mirrors publish md5sums files alongside SHA-256 ones for old scripts. Database engines and replication tools compare rows by MD5 because it is everywhere and fast enough. Legacy protocols and enterprise file formats bake it into manifests that will outlive us all.
Meeting MD5 in these places is not a finding; replacing it there has real cost and no security payoff. The audit question is a different one: does anything on the other side of the hash have an incentive to collide it? If yes, it is a vulnerability with a 2004 CVE mindset; if no, it is plumbing.
What to use instead
| Job | Use | Why |
|---|---|---|
| Anything an attacker touches | SHA-256 | unbroken, universal support |
| Fast integrity, trusted ends | xxHash3, CRC32 | far faster, honest about being non-cryptographic |
| Fast and cryptographic | BLAKE3 | MD5-class speed with real security, if both ends support it |
| Message authentication | HMAC-SHA256 | keyed, immune to the collision story entirely |
| Passwords | bcrypt / Argon2 | salted and deliberately slow, which no plain hash is |
Our own rule when touching old systems: never introduce a new MD5, never rip out a harmless old one on principle alone, and write the replacement ticket the moment the hash guards anything an outsider can influence.
Where MD5 is still fine
Is MD5 still safe to use for file checksums?
Against accidents, yes; against people, no. MD5 still catches corrupted downloads, bit rot and truncated transfers as reliably as ever, because random damage will not land on one of its collisions. What it cannot do since 2004 is resist an attacker: colliding MD5 pairs can be generated in under a second on a laptop, so a malicious party can ship two files with the same MD5. Rule of thumb: verifying against a checksum you already trust from a source nobody can tamper with is tolerable; anything where an adversary could substitute content needs SHA-256.
Can you decrypt an MD5 hash back to the original text?
No, and not because the attackers are not trying: MD5 maps every possible input to 128 bits, so infinitely many inputs share each digest and no algorithm can pick "the" original back out. What the "MD5 decrypt" sites actually do is look your hash up in a table of billions of precomputed hashes of leaked passwords and common strings. A hash of "sunshine1" will be in the table; a hash of 16 random bytes will not. That lookup attack, and the rainbow-table variant of it, is exactly what salting was invented to break.
How do I compute an MD5 hash on the command line?
Linux: md5sum file. macOS: md5 file, or md5 -q file for the bare hash. Windows: certutil -hashfile file MD5, or Get-FileHash file -Algorithm MD5 in PowerShell. OpenSSL everywhere: openssl dgst -md5 file. For a string, watch the newline: echo "text" pipes text plus into the hash, echo -n "text" hashes only the text, and the two digests are completely different, which is the most frequent "why does my MD5 not match" of them all.
Why is the MD5 of my file different from the published one?
The bytes differ, even if the content looks the same. Common causes, roughly in order: the download is genuinely corrupted or incomplete (check the file size first); line endings were converted between CRLF and LF by Git, an editor or an FTP client in text mode; the published value belongs to a different version or the uncompressed variant of the archive; or one side hashed with a different algorithm and the lengths just happen to be misread. A 32-character value is MD5, 40 is SHA-1, 64 is SHA-256; this page names the mismatch when a pasted checksum has the wrong length.
What is an MD5 collision, and how easy is it to make one?
Two different inputs with the same MD5 digest. Wang and Yu published the first in 2004; today the fastcoll tool produces a colliding pair in well under a second on ordinary hardware, and chosen-prefix collisions (where both files start with content the attacker picks, the dangerous kind) take hours. The 2008 rogue-CA demonstration used exactly that to forge a trusted TLS certificate, and the Flame malware in 2012 forged a Microsoft code-signing certificate the same way. That is why "MD5 for anything an attacker touches" ended as a hard no more than a decade ago.
What still uses MD5 today?
A surprising amount of plumbing where collisions do not matter: S3 ETags for single-part uploads are the MD5 of the object, many mirror networks still publish md5sums alongside newer digests, database replication tools use it for fast row comparison, and countless internal caching and deduplication schemes key on it. These are integrity and identity checks among trusted parties, which MD5 still handles. The places it must not appear, certificates, signatures, password storage, all made news precisely because MD5 lingered there too long.
What should I use instead of MD5?
For anything security-relevant: SHA-256, universally supported and unbroken. For pure speed where you only fear accidents, non-cryptographic hashes like xxHash3 are an order of magnitude faster than MD5, and BLAKE3 gives you cryptographic strength at similar speed if you control both ends. For passwords, none of the above: password storage needs a salted, deliberately slow function like bcrypt or Argon2, which is a different tool category entirely.