MD5 hash generator

The installer has finished downloading, the vendor published exactly one checksum next to it, and that checksum is 32 characters of MD5. Cryptographers stopped recommending MD5 in 2004, and for the job in front of you it is still very probably fine — a more useful answer than either “MD5 is broken” or “MD5 is good enough”. Every input returns 128 bits, however many bytes went in, and it returns them fast, which is why MD5 is still wired into software written long after it fell.

The one job MD5 still does well

MD5 is excellent at answering a single question: did this file change by accident? A flipped bit in a download, a copy that stopped halfway, a sector going soft on a ten-year-old drive, a transfer over a flaky cable — MD5 catches every one of them, because accidental damage has no idea what digest it is aiming for. The chance of a random corruption landing back on the original 128-bit value is about one in 340 undecillion, which is to say it does not happen.

For that purpose MD5 and SHA-256 are equally good and you lose nothing by using whichever one is in front of you. If a vendor publishes only an MD5, check the MD5. The problem begins the moment you ask the digest a different question.

What broke in MD5, and what did not

MD5's failure is specific, and the specifics are what tell you whether your own use is affected. Two separate properties are in play, and only one of them is gone.

• Collision resistance. Nobody should be able to find any two different inputs that share a digest. MD5 lost this in 2004, when Xiaoyun Wang's team published a working method. It has only got cheaper since: a colliding pair of files is now the work of a second or two on an ordinary laptop.
• Preimage resistance. Given a digest and nothing else, nobody should be able to find an input that produces it. MD5 still has this. The best published attack is barely better than trying candidates one at a time, and at 128 bits that is not a plan.

The practical consequence is narrower than the headlines suggest, and the narrowness is the useful part. A collision attack requires the attacker to author both files. They construct a harmless document and a harmful one that happen to hash identically, get you to approve, sign or publish the harmless one, and then substitute the other. What the attack does not give them is the ability to take a file you already have — an installer in your Downloads folder, a contract you wrote yourself — and build a different file matching its MD5. That is a second preimage, and it remains out of reach.

So the rule is not “MD5 is broken, never touch it”. The rule is: if somebody who wants to deceive you gets to choose the bytes, MD5 is no longer evidence of anything. Whether MD5 is still safe works through the common uses one at a time, and MD5 against SHA-256 covers what you actually gain by switching.

Where you still meet MD5

• Download pages for older software and firmware, usually as a small .md5 file sitting beside the archive, sometimes alongside a SHA-256 for the same file.
• Amazon S3 ETags. For an object uploaded in one piece the ETag is the MD5 of its contents, which is why people reach for MD5 to confirm an upload landed whole. Multipart uploads get a digest of the part digests with a hyphen and a part count after it — not the file's MD5, and a reliable source of an afternoon lost.
• Old archive manifests. A .md5 file written in 2009 is still a sound record of what a disk looked like in 2009, as long as the question you are asking it is “has this rotted?” rather than “has anyone been at this?”
• Cache keys and content addressing inside systems where nobody hostile gets to choose the content, and where a digest is an index rather than a guarantee.

When only an MD5 is published

Use it, and be clear with yourself about what it bought you. If you fetched the file over HTTPS from the vendor's own domain, then TLS and the certificate did the identity work; the MD5 confirms the bytes survived the trip. That is a sensible division of labor, and it is most of what checksum verification achieves in practice anyway — see verifying a download for the rest of it.

Where both an MD5 and a SHA-256 are offered, check the SHA-256. It costs you the same single read of the file, and it answers both questions instead of one. Getting both values out of that one read is a job for an app on your Mac rather than anything in a browser tab — hashing a file on a Mac covers how it goes.

Why MD5 lookup sites appear to decrypt it

MD5 cannot be reversed — it discards information, so there is nothing to undo. What it can be is looked up. MD5 is fast and its output is fixed, so somebody has long since computed and stored the digest of every dictionary word, every leaked password, every four-digit PIN and every common name-and-year combination. A site advertising MD5 decryption is searching that table. It will read hunter2 instantly and it will never touch a 40-character passphrase.

The same arithmetic is why an MD5 password column is a liability rather than a protection: a current GPU grinds through billions of MD5 candidates a second, so an unsalted column of MD5 hashes is a list of plaintext passwords with an extra step. Password storage wants a function designed to be slow — bcrypt, scrypt or Argon2. The same objection applies to SHA-256, for the same reason.

Is MD5 actually faster?

It used to be, reliably, and on a modern Mac it often is not. Apple Silicon has dedicated SHA-256 instructions in hardware and nothing comparable for MD5, so the gap that made MD5 the pragmatic choice in 2005 has closed and in places reversed. On a real file the argument is moot regardless: both algorithms can consume data faster than a typical drive supplies it, so what you are timing is your storage, not your choice of function.

Which is why the choice is rarely worth the argument it gets. A tool that reads the file once and computes MD5 and SHA-256 together costs the same wall-clock time as either one alone, and leaves you holding both values instead of a decision you have to defend later. That is what a single pass over a file buys you in a native window, and what one pass over a whole folder buys you at the other end of the scale.

Checking a folder full of old .md5 files

A string is one thing. A directory with a decade-old .md5 sitting in it, and a question about whether anything inside has rotted, is a different shape of problem entirely. At a thousand files, pasting values one at a time stops being a method.

It helps to know what those old files look like, because the format has barely changed in thirty years. One line per file, the digest first, two spaces, then the name it belongs to:

d41d8cd98f00b204e9800998ecf8427e  notes.txt
9e107d9d372bb6826bd81d3542a419d6  *the-quick-brown-fox.txt
c3fcd3d76192e4007dfb496cca67e13b  lowercase-alphabet.txt

Thirty-two characters in the first column is how you know it is MD5 before anybody tells you, and an asterisk before a filename means that file was read in binary mode, which on a Mac changes nothing about the digest. A SHA256SUMS file is the same shape with longer values — what a SHA256SUMS file looks like sets out the layout the rest of the world expects a checksum file to be in.

Rocket Hash computes MD5 natively, filed under LEGACY beside SHA-1 so that nobody picks it up by accident, and free to use on text. Drop the directory into the Files tool and it works through everything underneath it — one row per file, each file read exactly once however many digests you asked for, a summary on the left of the status bar and a progress count on the right of it while it runs, and at the end a shasum-compatible manifest in exactly the shape above: the record to set against the old file, and to keep for the next time the question comes up. For a single line out of an old list there is a shorter route — paste those 32 characters into the Verify tool, drop the file they name beside them, and read a verdict instead of comparing by eye. Generating an MD5 on a Mac walks through a string and a folder in turn, and checking files against a manifest covers the comparison across the whole directory.