How to verify a download on Mac

An installer is sitting in ~/Downloads and you would like to know whether it is the file the publisher meant to hand you. Verifying a download means recomputing the published digest from the bytes that actually reached your disk: if the two strings match, your copy is the published copy to the byte, and if they do not, you do not yet have the file you went looking for.

It takes about as long as reading the file once, and the arithmetic is the easy half. The judgment is in which value you compare against, because a checksum is only ever as good as the place you got it from. This page covers both halves: where the real checksum lives, and how to get an unambiguous answer out of it.

If hashes are new to you, what a checksum actually proves is the five-minute version. If you already have the value in your clipboard and just want the mechanics, checking a file’s checksum is the general route, downloads or not.

What verifying a download proves, and what it does not

A match tells you one thing very precisely: the bytes on your disk are the bytes that produced the published digest. That covers every kind of accidental damage there is — a transfer that stopped early, a flipped bit on a drive that is starting to fail, a corporate proxy that rewrote something in flight, a resumed download that stitched itself back together in the wrong order. None of those can survive a comparison: flipping one bit of the input flips about half the bits of the digest, which changes almost every one of its 64 characters.

Three things it does not tell you, and all three get assumed:

• Nothing about safety. A verified file is an unaltered file. If the publisher shipped something malicious, a matching checksum confirms you received it intact.
• Nothing about who made it. Anyone who can change the file on a server can usually change the checksum printed next to it. Integrity and authenticity are separate claims, and a signature is what joins them — detecting tampering covers the condition under which a digest becomes evidence of origin.
• Nothing about the copy you end up running. You are checking the archive as it arrived. After an installer has run, what is on disk is not what you hashed, and re-hashing the installed app will not reproduce the published value.

Where the real checksum lives

Publishers are inconsistent about this, and the value is rarely next to the button you clicked. In rough order of how often you will find it:

• A checksum file beside the images. Linux distributions and most open-source projects publish one file listing every release artifact — SHA256SUMS, checksums.txt, *.sha256 — in the same directory as the downloads. Often there is a detached signature next to it, which is the part that makes it worth more than a formality. Verifying a Linux ISO works through a real example end to end.
• The release notes. On a GitHub release the maintainer frequently pastes the digests into the release body, or attaches a checksums file as one of the assets. This proves your copy matches what that account uploaded, which is usually exactly the question you had.
• A separate documentation page. Firmware, enterprise installers and anything with a support contract tend to list checksums on a page that is not the download page. Search the vendor’s own site for the file name rather than trusting the first result for “vendor checksum”.
• A package manager’s own record. Install through Homebrew, npm or pip and the expected digest is written into the formula or the lock file, checked as the package is fetched. That covers only what the manager itself downloaded — the installer, disk image or archive you clicked on in a browser is outside it, and that is the file this page is about.
• Nowhere. Plenty of perfectly legitimate software ships without a published digest. Say so to yourself rather than pretending a checksum you invented means something.

Two practical habits make a surprising difference. Take the checksum from the project’s canonical https site even when the file itself came off a mirror or a CDN, because the mirror is the part you are checking. And if a third party posted a digest in a forum thread, treat it as a second opinion rather than the authority — agreement between two independent sources is genuinely informative, and one stranger’s copy-paste is not.

Verify a download, step by step

1. Get the publisher’s value

   Copy the digest from the project’s own page or checksum file. There is no need to trim the filename off the end of a SHA256SUMS line first; the hexadecimal is the part that gets compared. Note which algorithm the page claims it is while you are there, though the length settles that on its own.

2. Make sure the download actually finished

   Compare the size on disk with the size the page advertises, and check the name no longer ends in .part, .crdownload or .download. A file that is still arriving will hash perfectly and match nothing, which is the single most common false alarm on this whole subject.

3. Match the value to the exact build

   Releases come in variants, and the digests are all different: Apple Silicon against Intel, .dmg against .pkg against .zip, the desktop image against the server image, 24.04 against 24.04.1. One glance at the file name against the line you copied prevents a mismatch that looks alarming and means nothing.

4. Hand both to the Verify tool

   Click Verify in the sidebar, choose Against a Checksum on the segmented control, drag the file into the drop well, and paste the value. The algorithm is read off the length of what you pasted, so there is nothing to configure.

5. Read the verdict and act on it

   One pass over the file and the answer is sitting underneath it, written out as a sentence with a green seal behind it when the two agree. If they do not agree, fetch the file again from the publisher rather than from the same mirror, and leave the first copy unopened while you do.

When the answer is the wrong one, work through the causes in likelihood order instead of assuming the worst — what to do when a checksum does not match does exactly that, and an interrupted download accounts for more mismatches than everything else combined.

What the browser did to your download

Most verification surprises happen between the server and the file you ended up pointing at, and the browser is usually responsible.

Safari can expand an archive as soon as it arrives, which leaves you with a folder and no .zip to hash — the digest was published for the archive, and the archive is in the Trash. Turning off the option to open “safe” files after downloading puts that back under your control. Chrome and Firefox append (1) to a second copy rather than overwriting, so the file you verify and the file you open are easily two different files. And a download that failed and resumed is worth re-fetching from scratch if it does not verify the first time; that is cheaper than diagnosing it.

What does not affect the result is everything macOS attaches to the file on the side. The quarantine flag, the record of which URL it came from, Finder tags and comments all live in extended attributes, which sit outside the file’s data and are never read by a hash.

So a file you downloaded and a file a colleague sent you over AirDrop can carry completely different metadata and still verify against the same published checksum. That is the intended behavior: the digest describes the contents, not the history.

When the publisher only offers MD5 or SHA-1

Check it anyway. A 32-character MD5 or a 40-character SHA-1 still catches every accidental corruption a download can suffer, and a publisher offering nothing better is not a reason to skip the check. Both algorithms lost their collision resistance years ago — MD5 comprehensively from 2004, SHA-1 once a real collision was demonstrated in 2017 — but a collision is a pair of files an attacker builds together, which is a different scenario from somebody altering a release you already have the digest for.

Where it matters is what a legacy digest cannot do if the answer is ever disputed. It still says “this arrived intact”; it no longer says “no other file could have produced this value”, and the second claim is the one a signature rests on. Is MD5 still safe? goes into which jobs it is still fine for, and which ones it has no business near.

Verifying more than one download at a time

One installer against one published value is a thirty-second job. Verification stops being a single event the moment a release has six artifacts, or an ISO gets re-fetched next month, or a folder of firmware images arrives at once — and a verdict you read once and then closed is not something you can hold the next copy up against.

In the window that becomes one job rather than six: drop the whole folder into Files with the Algorithm control set to SHA-256, watch the status bar count files and bytes on the left and progress on the right, and read every digest off one pass over each file. Because each file is streamed rather than loaded, memory stays flat at roughly 16 MB whether an installer is 40 MB or 12 GB, and a long run pauses mid-file and resumes from the exact byte it stopped on. The export control then writes the lot out as a shasum-compatible manifest, which is what you compare the same downloads against the next time somebody re-uploads them.

For the single download this page is about, Verify is the narrower tool, and it has a second mode worth knowing: File vs. File, for when nobody published a digest and all you have is two copies fetched separately. Either mode ends in a sentence and a seal rather than two 64-character strings for you to read across, which is where comparing by eye goes wrong — attention fails somewhere around the twelfth character.

Troubleshooting

The page lists a checksum but not for my file

Check whether it belongs to an archive that contains your file rather than to the file itself — projects often publish a digest for the .zip and nothing for the application inside it. If the variant you downloaded genuinely has no published value, a digest for a different variant is not a substitute; there is nothing to verify against, and it is better to know that than to compare the wrong two things.

There are three checksums and I do not know which to use

Use the strongest one listed, which in practice means SHA-256 over SHA-1 over MD5. You are not choosing an algorithm for its own sake — you are choosing which of the publisher’s values to reproduce, and reproducing the best one costs you nothing extra because the file is read once either way.

The checksum matches but macOS will not open the app

Those are unrelated checks, and both can be true at once. A checksum says the bytes are unchanged; Gatekeeper asks whether the developer signed and notarized the build, which is a question about credentials rather than contents. An unsigned app verifies against its published digest perfectly and is still refused, and a notarized one can still be the wrong build. Do the checksum first, because it is the one that tells you whether you have the right file at all.

I already installed it before checking

If the downloaded archive is still around, verify that — it is the thing the digest describes. If the installer deleted itself, re-downloading purely to compare digests is a legitimate move and usually faster than it sounds. Hashing the installed application will not help, because installation unpacks, relocates and sometimes rewrites files.

Nobody published a checksum at all

You can still detect a tampering mirror without any help from the publisher: download the file a second time over a different network and check the two copies against each other, which comparing two files covers. It is a weaker claim than a signed digest, and it is considerably better than nothing. Record the digest of the copy you keep, too, so the next version has something to be compared against.

Frequently asked questions

Do I really need to verify every download?

No, and pretending otherwise is how people stop doing it at all. It is worth the thirty seconds for anything that will run with your privileges or write to a disk — installers, disk images, firmware, ISOs you are about to boot from — and for large files over a flaky connection, where a silent truncation is a real possibility. A PDF from a colleague does not need it.

Where do I find the checksum for a download?

Look in the directory the download itself came from for a file named SHA256SUMS, checksums.txt or similar; then the release notes, where maintainers often paste the digests; then the project’s documentation or support pages. Take the value from the publisher’s canonical site rather than from the mirror that served you the bytes, since the mirror is the part you are checking.

Does a matching checksum mean a download is safe?

No. It means the file is exactly what the publisher published, which is a claim about integrity, not about intent. If the publisher shipped malware, a matching digest confirms you received the malware intact. Verification protects you from damage and substitution in transit, not from the author.

Is checking the file size enough?

It catches a truncated download, which is worth something, and nothing else. A file can have exactly the right size with a bit flipped in the middle, and no amount of staring at the size will show it. A digest covers every byte, which is the entire point of using one.

Does the quarantine flag macOS adds change a download’s checksum?

No. Quarantine, the record of which site a file came from, Finder tags and comments are all extended attributes, stored alongside the file rather than inside it. A hash reads the file’s data, so a freshly downloaded copy and one that has been cleared of its attributes produce the same digest.

What if the publisher does not publish a checksum at all?

Then there is nothing to verify against, and it is better to say so than to compare the file with a digest from an unrelated source. What you can still do is download the file a second time over a different network and check the two copies against each other, and record the digest of the copy you keep so that the next release has a reference point.

Do I need to know which algorithm the published checksum uses?

Not usually. Drop the file into the Verify tool, paste the value into Against a Checksum, and the algorithm is read off the length of what you pasted — 32 characters is MD5, 40 is SHA-1, 64 is SHA-256, 128 is SHA-512. It is worth a glance at what the publisher called it for one reason only: a few lengths are shared between families, since SHA-256 and SHA3-256 are both 64 characters, and a page that lists a SHA-3 digest while saying “SHA-256” produces a mismatch that is nobody's fault.