MD5 Hash Generator

What is MD5?

MD5 — short for Message-Digest algorithm 5 — is a widely known hash function that was designed in 1991 and published by Ronald Rivest in 1992 as RFC 1321. It takes an input of any length and produces a fixed 128-bit digest: sixteen bytes, conventionally written as 32 hexadecimal characters. That digest behaves like a fingerprint for the input: change any single bit of the input and the entire output changes, in a way that cannot be predicted.

MD5 was one of the first hash functions to achieve mass adoption. It replaced its predecessor MD4, which had been weakened by cryptanalysis, and it became the default checksum for Unix distributions, FTP mirrors, file hosting, and countless databases. Its popularity outlived its security: MD5 is now considered cryptographically broken, yet billions of MD5 checksums still circulate through legacy systems and test suites. Understanding precisely where MD5 fails — and where it is still tolerable — is more useful than dismissing it outright.

At AnyHash, we compute MD5 entirely in your browser, so you can reproduce any legacy checksum without sending the input across the network. But we pair it with an honest warning: MD5 is unsuitable for passwords, signatures, and any security decision where an adversary could influence the input.

How MD5 works, step by step

Like most classical hash functions, MD5 is a block cipher spin-off built from a compression function. It processes the input in three phases: padding, message expansion, and a 64-step mixing loop.

1. Padding

The input is padded so its length becomes congruent to 448 modulo 512 bits. A single 1 bit is appended first, followed by enough 0 bits, and finally the original length as a 64-bit little-endian integer. Translating the length to bytes and processing little-endian first is a detail people often get wrong when re-implementing MD5 from memory — the raw bytes in the final padding block are the length, reversed byte by byte.

2. Message schedule

Each 512-bit block is split into sixteen 32-bit words. The algorithm then performs 64 operations, arranged in four rounds of 16. The first 16 operations use the message words directly; the remaining 48 combine words from earlier in the schedule, which diffuses influence across the whole block.

3. The four auxiliary functions

Each round uses one of four boolean functions over three 32-bit words, chosen so the four rounds mix in structurally different ways:

• F(X,Y,Z) = (X ∧ Y) ∨ (¬X ∧ Z) — a bitwise selector
• G(X,Y,Z) = (X ∧ Z) ∨ (Y ∧ ¬Z) — a rotated selector
• H(X,Y,Z) = X ⊕ Y ⊕ Z — parity
• I(X,Y,Z) = Y ⊕ (X ∨ ¬Z) — a variant of parity

Round constants are derived from the sine function: the k-th constant is ⌊|sin(k+1)| × 2³²⌋ for k = 0…63. This is the source of the oddly specific-looking numbers in every MD5 implementation.

4. State update

Five 32-bit registers named A, B, C, D, and a temporary carry the internal state. The four chaining variables start at fixed values (0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476). After all blocks are processed, the final A, B, C, D are appended in little-endian order to form the 128-bit digest.

The finished digest is what this page displays — 32 hex characters for every input, whether the input is the single letter a or a 4 GB file. A fixed output length is the defining property of a hash function, and it is why hashes can be compared so cheaply.

Why MD5 is considered broken

A cryptographic hash is only as good as its collision resistance, its preimage resistance, and its second-preimage resistance. MD5 fails the first one outright and is eroded on the others.

In August 2004, cryptographers Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu presented real collisions for the full 64-step MD5 — two distinct 1024-bit messages with an identical digest. Four months later, Wang and Yu collided on two 512-bit messages, and by 2005 the technique had been refined into a practical chosen-prefix attack by Marc Stevens, Arjen Lenstra, and Benne de Weger that allowed two arbitrary prefixes to be matched with a shared MD5 suffix.

The real-world consequences are not theoretical. In 2008, researchers used a chosen-prefix collision against the MD5 hash in a certificate-signing request to obtain a public CA-signed certificate for a key they did not control. The Flame malware of 2012 exploited a similar MD5 chosen-prefix collision to forge what appeared to be a Microsoft code-signing certificate. When a hash function lets two files share a digest, an attacker can substitute one for the other — and MD5 reached that point almost two decades ago.

Meanwhile, the throughput problem got worse. A single modern GPU cracks plain unsalted MD5 at roughly tens of billions of candidates per second, which means an 8-character password is exhausted in a matter of minutes. Rainbow tables — precomputed digest→input lookup tables — make the same attack near-instant for any password shorter than about ten characters when no salt is involved. For password storage, MD5 is not merely weak; it is effectively indistinguishable from no hashing at all.

MD5 vs SHA-1 vs SHA-256

MD5 and SHA-1 share a lineage: both are Merkle–Damgård constructions (MD4 → MD5, and MD4 → SHA-0 → SHA-1) and both are now deprecated. SHA-256 belongs to the SHA-2 family, whose design fixes the structural weaknesses of its predecessors and has held up to two decades of public cryptanalysis.

The bottom line of the table: for file integrity, digital signatures, TLS, and anything adversarial, use SHA-256. It has no known practical collision, its 256-bit output means a birthday collision costs around 2¹²⁸ hashing operations — a number beyond the combined computing power of every machine on Earth — and it is native hardware inside every browser through the Web Crypto API, which is why AnyHash computes it instantly.

When MD5 is still safe to use

"Cryptographically broken" and "useless" are different statements. The phrase cryptanalysis targets is collision resistance: an adversary being able to manufacture two messages with the same digest. When no adversary exists, MD5's collision weakness is irrelevant to you. There are a handful of situations where reuse is defensible:

• Reproducing legacy checksums. A CI pipeline, FTP mirror, or vendor build script still prints MD5. Matching it locally — as this tool does — is the honest way to interoperate.
• Non-adversarial content deduplication. Comparing two files you already control, on systems where an attacker cannot inject a colliding file, is safe in practice.
• Matching against existing MD5 databases. Virus-total-style lookups that have accumulated MD5 records for a decade remain queryable; the hash itself is not the security boundary, the reputation database is.
• Teaching and testing. MD5 is small, well-documented, and every reference vector is public — a fine model for learning how hash padding and the Merkle–Damgård loop work, as long as you label it deprecated in production-facing code.

In all of these cases the governing question is the same: could a deliberate actor control both inputs to the hash? If yes, MD5 fails. If the input cannot be influenced adversarially, the checksum still works as a consistency check.

When MD5 is dangerous

• Storing passwords. Any modern GPU can try ten billion MD5 candidates per second. Use bcrypt or Argon2id, which sacrifice speed on purpose.
• Verifying downloaded software against a public checksum. If a mirror or content distribution network is compromised, an attacker substitutes both the file and its MD5 in the same breath. Use SHA-256, which is what every serious release channel publishes today.
• Digital signatures and certificates. The 2008 chosen-prefix attacks against certificate authorities were only the first documented instance. MD5 signature verifiers must be treated as untrusted.
• Any protocol where collision resistance is a property (HMAC-MD5, TLS, SSH). All of these have been marked obsolete or security-weak in modern RFCs and browser implementations.

The mnemonic we recommend: MD5 for checksums, SHA-256 for integrity, bcrypt or Argon2id for secrets. Each has a lane; keep them in theirs.

How the AnyHash MD5 tool works

This page's tool is deliberately small and auditable. The Web Crypto API does not expose MD5, so the calculation runs on a compact, dependency-free implementation in JavaScript that follows RFC 1321 exactly.

• Nothing leaves the page. Your input is converted to bytes inside your browser and digested there. Open DevTools → Network and you will see no requests carrying your data.
• Three input encodings. UTF-8 text, raw hex bytes (abc → 61 62 63), and Base64. Choosing Hex lets you hash the literal bytes of a previous hex dump instead of the characters spelling it.
• On-device hashing, debounced. Every keystroke schedules a fresh digest of the whole input ~160 ms later, so results appear "live" while the main thread stays free. Files up to 64 MB are read into memory with FileReader and hashed in one pass.
• Instant feedback. The status line reports the digest time in milliseconds, the byte count, and the 32 hex characters of the output — so you can confirm with the worked examples below that the implementation matches every published reference.
• Uppercase or lowercase, copy or download. The output case matches what your consumer expects (Windows tools and hashes published in logs are commonly uppercase), and the download button writes a small .txt file in the same shape as md5sum output.

Worked examples you can verify right now

Paste each line into the tool above and you will get exactly these values. All four are from the original RFC or the longest-standing test vectors:

Compare rows three and four: a single period appended at the end — one byte of the sentence — produces a completely different 32-character digest. This is the avalanche effect that makes hashes useful for change detection, and it is the same property that lets a collision (two different inputs, one digest) be exploited so severely.

How to verify an MD5 checksum

The classic "did this copy succeed?" workflow still runs on MD5. To check a downloaded file:

1. Get the expected checksum from the source you trust (the vendor's page, not the same mirror that served the file).
2. Drop the file onto this page — or run md5sum filename on Linux/macOS or CertUtil -hashfile filename MD5 on Windows.
3. Compare the two digests down to the last character. Any difference means the file is not what the source intended.

For release-critical software, prefer the SHA-256 value a vendor publishes, and ideally a signed checksum file rather than a bare digest. MD5 still answers "did anything flip in transit?"; it no longer answers "is this file authentic?" — and knowing which question it is answering is the whole point of this guide.

Beyond collisions: MD5's other structural weaknesses

Collision resistance is not the only property a hash can lose, and MD5 loses others too. Three are worth knowing:

• Length extension. MD5 is a Merkle–Damgård construction: it processes the message block by block and carries a 128-bit internal state between blocks. Given MD5(secret || message) — a common way people "sign" data by concatenating a secret — an attacker can compute MD5(secret || message || extra) without knowing the secret. This surprises a lot of developers, and it is one more reason MD5 is wrong for authentication and MAC purposes. If you need a keyed primitive, HMAC was designed for exactly this.
• Chosen-prefix collisions. Beyond finding any two inputs that collide, cryptographers found a way to choose both prefixes: design two documents that are different but share a digest. Stevens et al. demonstrated this in 2007, and the Flame malware used a chosen-prefix collision in 2012 to make a rogue update cert appear validly trusted by Microsoft's code-signing. This is the attack that moved MD5 from "illustrate a textbook weakness" to "real-world assassination" — security vendors, then operating systems, banned MD5 certificate signatures.
• Preimage and second-preimage are weaker than ideal. Ideal 128-bit hash has 2¹²⁸ preimage resistance and 2¹²⁸-ish. Practical MD5 preimage search is faster than brute force (the best published techniques beat 2¹²⁸, using time-memory tradeoffs), and second-preimage attacks also beat the birthday bound — though both are still dominated by collision attacks, which run at about 2³⁹, a few minutes-to-hours on a modern laptop.

Threat models, in plain terms

A collision breaks MD5's usefulness only in a specific threat model: an adversary who can choose one of the inputs outranks you. "Will this release binary differ from what I uploaded?" — MD5 still answers faithfully, because an accidental or even deliberate byte flip does not change the source who could compute the collision; "is this software actually what the vendor shipped?" is a questions it can no longer bear, because the publisher of the collision could be the very person who wrote the file.

The practical rule that falls out of this: use MD5 as an accident detector, never as an authenticity oracle. If adversary selection enters the picture — anything involving a MAC, a certificate, a signature, a firmware update, an SDK you hand to the public — switch to a modern hash that the community still trusts, and better, use a signed checksum (GPG, minisign, a code-signing cert) so "who made this" is answered cryptographically rather than by digest equality.