How to generate an MD5 hash on Mac

You have met an MD5 somewhere it is too late to argue with. An older mirror that publishes nothing else. A vendor's release notes with 32 characters and a contact address from another decade. A build pipeline that fingerprints artifacts with MD5 because it was written when that was the obvious choice. Meanwhile every checklist you have read says MD5 is broken, and you would like to know whether using it makes you complicit in something.

Where MD5 sits on screen is half the answer already: under the heading LEGACY, paired with SHA-1, at the bottom of the eight. It still resolves as you type in the Text tool, and for a file it still comes out of the same single read as the other seven — 32 hexadecimal characters, 128 bits, 16 bytes. For a second opinion on a string — not a file — the MD5 generator on this site computes it in your browser as you type.

The security question has a precise answer rather than a vibe. MD5 is still perfectly good at catching a file that arrived damaged. It is useless for proving that a file is the file somebody promised you. Those are two different properties with two different names, and almost every bad argument about MD5 comes from running them together.

What the 32 characters are

MD5 takes input of any length and returns 128 bits, written as 32 hexadecimal characters. Ron Rivest designed it in 1991, it was published as RFC 1321 the following April, and for roughly a decade it was the default fingerprint for everything. It is deterministic — the same bytes give the same digest on any machine in any year — and it has the avalanche behavior you want, where flipping one bit of the input changes about half the output.

Two values are worth committing to memory, because you will see them more often than you expect:

The first one is a diagnostic. If a file you believe contains 700 MB of installer hashes to d41d8cd9…, the file is empty and you have been looking at a stub rather than a download. The second is the RFC's own test vector, which makes it a two-second way to check that any tool is telling you the truth — testing a hashing tool against known answers does this properly across several algorithms.

Match a published MD5 on your Mac

1. Confirm it really is an MD5

   Count the characters in what you were given. 32 means MD5, and nothing else in use produces 32 — 40 would be SHA-1, 64 SHA-256, and 8 a CRC32. Pages that have not been edited in years are exactly the pages most likely to label a value wrongly, and comparing two different algorithms produces a mismatch that looks alarming and means nothing.

2. Hash your copy of the file

   Drag the file into Files. The row shows the name, the folder it came from, the size and a digest; the Algorithm control in the toolbar decides which digest that is, and the disclosure chevron on that row opens all eight at once with MD5 among them. Check the size against what the download page claims before you read any digest at all — a size that disagrees tells you the answer early.

3. Let the comparison happen for you

   Rather than reading 32 characters twice, hand both halves to Verify: choose Against a Checksum, drop the file in, paste the published value. A 32-character value could only be an MD5, so the algorithm follows from the length and you do not have to declare it. The verdict arrives as a sentence with a seal rather than two strings to compare by eye.

4. Decide what the match has told you

   A match means your bytes are the bytes whoever published that value hashed. If your only worry was a truncated download or a bad cable, you are finished and MD5 did the job properly. If your worry was whether the file is what its author claims, the digest has not answered that — and it would not have answered it in SHA-256 either, which is the subject of checking a file has not been tampered with.

What broke in MD5, and what did not

A cryptographic hash is asked to resist three different attacks, and MD5 has failed exactly one of them. The distinction is not academic — it is the difference between the two halves of this page.

Collision resistance went first and went badly. Xiaoyun Wang and Hongbo Yu announced working MD5 collisions in 2004, and the cost has only fallen since; what once took hours on a cluster now takes moments on the machine in front of you. Worse, the attacks became chosen-prefix collisions, which means an attacker can write two documents that differ however they like and still arrange for the digests to agree. That is not a curiosity. A rogue certificate authority was demonstrated against MD5-signed certificates in 2008, and the Flame malware used an MD5 collision to forge a code-signing certificate in 2012.

The other two properties have held. There is no known way to take a digest and recover an input, or to take somebody else's file and build a different file matching its digest, that beats trying candidates one at a time — and 2 to the power of 128 candidates is not a number anyone is working through. This is why MD5 still catches corruption perfectly well: a cosmic ray, a failing cable and a truncated copy cannot choose their bytes, and damage that cannot choose its bytes has no way of landing on the same digest.

This also settles the sites offering to “decrypt” an MD5. Preimage resistance is precisely the property MD5 kept, so nothing is being recovered — they are searching a dictionary of digests for strings people commonly hash. That works on letmein and on nothing outside the dictionary, which is the same reason a general-purpose hash is the wrong tool for storing passwords.

MD5 is not even the fast option any more

The old argument for MD5 was speed: it was the cheap hash, and when you had thousands of files to fingerprint that mattered. On a modern Mac that argument has inverted. Apple Silicon carries dedicated instructions for SHA-256 and none for MD5, so the newer and supposedly heavier algorithm is the faster one — SHA-256 reaches roughly 2 GB/s on that hardware, while MD5 is computed in ordinary arithmetic like any other code.

So choosing MD5 to save time on a Mac saves no time at all. The remaining reasons to use it are compatibility reasons — something else published an MD5, or expects one — and those are perfectly good reasons. MD5 vs SHA-256 sets the two side by side; whether MD5 is still safe takes the security argument further than this page does.

When there is more than one MD5 to deal with

Inherited MD5s rarely arrive one at a time. A backup set has a value for every file, an old release has a list, a pipeline somebody wrote in 2011 emits one per artifact. Drop the whole folder into Files and every file inside becomes its own row; set the Algorithm control in the toolbar to MD5 once and it applies to all of them, while the status bar keeps a summary on the left and a running count of what has finished on the right. It is built for six-figure file counts, and memory stays flat at roughly 16 MB throughout, because no file is ever held whole.

The useful part, if your intention is to get off MD5 rather than stay on it, is that each file is read exactly once however many digests you asked for. The pass that produces the MD5 your old manifest expects produces the SHA-256 you would rather publish in the same breath, with no second trip over the disk. That turns a migration into one job instead of a choice between two.

What comes out — and, more to the point, what you will be handed — is the two-column shape every checksum list on the internet uses: the digest, two spaces, the filename, one line per file. A folder holding an empty file and a file containing the three letters abc looks like this:

d41d8cd98f00b204e9800998ecf8427e  empty.txt
900150983cd24fb0d6963f7d28e17f72  abc.txt

Nothing in that file says which algorithm made it, which is a real weakness of the format and the reason the character count is the first thing to read. Here it happens to be unambiguous: 32 characters can only be MD5. Take any single line, drop the file it names into Verify and paste the digest, and you have checked one entry without reading hex twice; the export control writes the same shape back out when you need to hand a list to somebody else. Exporting a checksum manifest goes through the format properly.

Troubleshooting

Verify never asked me which algorithm to use

It works that out from the value you paste, because the length gives it away: 32 hexadecimal characters can only be an MD5, 40 only a SHA-1, 64 only a SHA-256. The one thing that matters, then, is pasting the whole value — a checksum that lost a character somewhere between a web page and your clipboard is no longer 32 characters, and no longer an MD5 as far as anything reading it is concerned.

The published value reads MD5 (file) = digest

That is the older BSD layout, and plenty of download pages that have not been touched in a decade still use it. Only the tail of the line is the checksum: the 32 characters after the equals sign, and that is what goes into Verify — not the whole line, and not the filename in the parentheses. Lists from Linux-flavored tooling put the digest first instead, two spaces, then the name. Both describe exactly the same thing, and neither states the algorithm anywhere, so count the characters before you trust whatever the page calls it.

I got d41d8cd98f00b204e9800998ecf8427e

That is the MD5 of nothing, so the file you hashed is zero bytes. Look at the size in the file row: a failed download that left a stub, a file that was created but never written, or the wrong item picked from a folder will all do this. The digest is correct; the input was not what you thought.

The text I typed hashes differently from the file

Almost certainly a trailing newline. Text editors add one when they save, while a text field does not, and one extra byte changes every character of the digest. The byte count under the text field is where you catch it: the three letters abc read 3 bytes, and the same three letters saved to a file and hashed read 4 — 900150983cd24fb0d6963f7d28e17f72 against 0bee89b07a248e27c83fc3d5951213c1. A file containing nothing but a single newline has the MD5 68b329da9893e34099c7d8ad5cb9c940, which is worth recognizing on its own.

A security scan flagged MD5 in our code

Find out what the digest is used for before rewriting anything. If it is a cache key, a shard selector or a way of noticing that a row changed, MD5 is doing a non-security job and the finding is noise — although switching to SHA-256 usually costs one string and silences the scanner. If it guards a download, verifies an update, or decides that two uploaded files are the same thing, the finding is real and the fix is not optional. Working through a mismatch is the other half of doing this properly.