MD5 hash generator

MD5 is not weak, it is broken: two different inputs producing the same digest can be constructed deliberately, in seconds, on an ordinary laptop. The first collision was published in 2004 and the technique has only got cheaper. There is no configuration, no salt and no length that repairs this.

What it does not mean is that MD5 has become unpredictable or that existing digests have stopped matching. A collision is something an attacker constructs; it is not something that happens by accident. That distinction is the whole of the remaining use case — MD5 is finished wherever somebody might be trying to fool you, and unaffected where nobody is.

Detecting accidental corruption. A file that was truncated in transit or flipped a bit on a bad disk will not produce the same MD5, because nothing was trying to make it. Deduplication for the same reason: two identical files have the same digest, and the odds of two unrelated real files colliding by chance remain astronomically small.

Reproducing something that already exists is the other one, and it is why most people are here. A cache key, an ETag, a Gravatar URL, a column in a database somebody chose fifteen years ago — the algorithm is not a choice in those cases, it is a fact about a system you have to interoperate with.

Passwords. Storing a password as an MD5 — with or without a salt — is negligent rather than merely dated, because MD5 is fast, and fast is exactly wrong for a password hash. Consumer hardware tries billions of MD5 candidates per second; the whole point of bcrypt, scrypt and Argon2 is that they cannot be hurried.

Anything you are trusting. A signature, a certificate, a software download whose publisher wants you to verify it, a token you check for tampering. In every one of those there is an adversary who benefits from a collision, and producing one is not hard. Use SHA-256, which is one page away.

MD5 takes bytes, and text is not bytes until an encoding is chosen. This page uses UTF-8, which is what files, databases and request bodies overwhelmingly hold. A system that stored the same text as Latin-1 or UTF-16 will produce a different digest for what looks like the same string, and neither side is wrong.

That is the usual reason two MD5s of "the same" text disagree. Before assuming an implementation is broken, check the encoding, then check for a trailing newline — the second most common cause, since a file usually ends with one and a text box does not.

A digest is a number; upper and lower case are two ways of writing it and every parser accepts both. Lower case is the Unix convention and what `md5sum` prints. Upper case turns up in Windows tooling and in a lot of older documentation.

The one place it stops being cosmetic is a comparison done as strings. Two digests of the same value, one in each case, are visibly identical and fail an equality check — which survives review precisely because the two values look the same on screen. Normalise before comparing, or compare case-insensitively.