BRev MD5 hash generator
MD5 produces a 128-bit digest, written as 32 hexadecimal characters. It was designed in 1991 and it is comprehensively broken for security — but “broken” has a specific technical meaning that decides whether your particular use is a problem, and most warnings never say which.
What is broken is collision resistance. Since 2004 it has been possible to construct two different inputs with the same MD5 digest, and today it takes seconds on a laptop. That destroys every use where an attacker controls the input: digital signatures, certificates, deduplication of untrusted files, and any “this file is approved because its hash matches” check where the file was supplied by someone else. The Flame malware in 2012 used an MD5 collision to forge a Microsoft code-signing certificate.
What is not broken is preimage resistance: given a digest, there is still no practical way to find an input that produces it. That is why MD5 remains legitimate for detecting accidental corruption — a mirror’s MD5SUMS file, a database checksum column, a cache key, an ETag. If the only adversary is a truncated download or a flipped bit, MD5 does the job. If there is an adversary at all, use SHA-256.
MD5 in numbers
| Property | Value |
|---|---|
| Output | 128 bits — 32 hex characters |
| Block size | 512 bits |
| Published | 1991 (Ronald Rivest), RFC 1321 |
| Collision resistance | Broken — practical collisions since 2004, seconds on ordinary hardware |
| Preimage resistance | Not practically broken — best attacks remain infeasible |
Is MD5 safe to use — and for what?
“Broken” and “fine” are both true of most hash functions depending on the job, so the answer is per use, not per algorithm.
| Use | Verdict | Why |
|---|---|---|
| Verifying a download against a checksum on the same page | Yes | It detects corruption and truncation reliably. It does not protect against a compromised mirror that published both file and checksum — for that the signature matters, not the algorithm. |
| Cache keys, ETags, deduplication of your own content | Yes | No adversary supplies the input, so collisions are not reachable. MD5 is fast and 128 bits is plenty for accidental-collision purposes. |
| Password storage | No | Never — and not because of collisions. MD5 is far too fast: commodity GPUs compute tens of billions per second, so any password list falls quickly. Use bcrypt, scrypt or Argon2, which are deliberately slow and salted. |
| Digital signatures and certificates | No | Collisions let an attacker prepare two documents with the same digest and swap them after signing. This has been exploited in the real world; every CA and signing scheme has moved to SHA-256. |
| Integrity of a file an untrusted party supplied | No | The attacker controls the input, so a collision is constructible. Use SHA-256 for anything where somebody would benefit from a match. |
FAQ
Is MD5 safe to use?
For accidental-corruption checks, yes. For anything an attacker could influence — signatures, certificates, passwords, verifying untrusted files — no. The distinction is collisions (broken) versus preimages (not).
Can MD5 be decrypted or reversed?
No — it is a one-way function, not encryption. What rainbow tables and cracking sites do is look up or brute-force common inputs. Anything short or predictable is recoverable that way; that is a speed problem, not a reversal.
Why do projects still publish MD5 checksums?
Momentum, ubiquity, and the fact that it genuinely detects corruption. Most now publish SHA-256 alongside it. If both are offered, verify the SHA-256.