How to hash a DMG file on Mac

The disk image is in your Downloads folder. It came from the developer's site, or from a GitHub release page, and somewhere near the download link there is a 64-character string you are now wondering whether to bother with. macOS has a whole apparatus for vetting downloaded software, and a hand-copied hash can feel like a ritual left over from before that existed.

It is not, but the reason is narrower than most write-ups suggest. Hash the .dmg exactly as it arrived, before you double-click it. Compare it with the value the developer published. Then open it and let macOS do its own, rather different, checking. Both halves together take under a minute, and they answer two separate questions.

What follows separates the two questions, sets out the four situations where the checksum is the only evidence you hold, and is honest about where it adds very little. If you want the general routine rather than the DMG specifics, verifying a download on Mac is the broader version.

What macOS already checked

When a browser downloads a file, it tags that file with a quarantine attribute. The first time you open a quarantined disk image, or launch a quarantined application, macOS stops and assesses it: is this code signed with a Developer ID certificate, and has it been notarized — sent to Apple, scanned automatically, and issued a ticket saying so?

That assessment is cryptographic, and in one respect it is stronger than any checksum. A code signature covers the executable and every resource in the bundle and is bound to a certificate issued to a named developer. Alter one byte inside a signed app and the signature no longer validates, and macOS will decline to launch it without a deliberate override from you. None of that requires a published digest, a download page, or you doing anything at all.

So say the honest thing first: for a signed, notarized app from an identified developer, fetched over HTTPS from that developer's own domain, a matching checksum confirms something the signature has already settled. It is not useless, but it is not the thing protecting you either.

What the checksum adds

Four situations where the digest is doing real work rather than decorating the page.

• It identifies the build, not just the publisher. A signature says these bytes came from whoever holds that certificate. It does not say which release you are holding. A published digest names one exact build — which is what you want when a developer has quietly replaced 3.2.1 twice, or when you need to record precisely what you rolled out to thirty machines.
• It covers software macOS cannot vouch for. Open-source builds, nightly snapshots, internal tools, anything from a developer without a paid Developer ID. macOS does not quietly wave those through: an unsigned or un-notarized build fails the first-open check whether its bytes are intact or not, and the override you click to run it anyway says nothing about the bytes. The digest is then the only integrity evidence in the room.
• It does not depend on how the file reached you. A disk image that arrived on a USB stick, through a file server, out of a colleague's archive or unpacked from another archive may carry no quarantine flag, and the first-open assessment can simply not happen. A digest does not care about provenance metadata; it reads the bytes.
• It tells corruption apart from tampering. Truncated downloads are vastly more common than attacks, and a partial disk image tends to fail to mount with a complaint that explains nothing. A length-and-digest mismatch says plainly that you have an incomplete file, not a malicious one.

There is a fifth use that only pays off later: record the digest of a build you have decided to trust, and you can prove in two years that the copy in your archive is still that build. What a digest proves about tampering covers the one condition that makes this worth anything, which is where the reference value lives.

Verify a DMG, then open it

1. Find the developer's published digest

   Look on the release page, in the release notes, or in a checksums file attached to the release — many projects post a small text file alongside the binaries rather than putting the hex in the page body. If there is nothing anywhere, that is an answer too, and the troubleshooting section below covers what to do with it.

2. Hash the DMG as it arrived

   In the Verify tool, choose Against a Checksum and drag the .dmg into the drop well — the file as downloaded, not anything inside it, and not a copy you have already moved and renamed. The well shows the name and size, which is the moment to notice you have picked up last month's version.

3. Paste the value and read the verdict

   Paste the published hex. The algorithm comes from its length, so 64 characters is taken as SHA-256 and 40 as SHA-1 without you declaring anything. A few seconds later you get a green seal and a sentence, or a plain statement that the two do not agree.

4. Open it and let macOS take its turn

   Now double-click the image, drag the app where it belongs, and launch it. This is where the signature and notarization check happens, and it is a genuinely different test from the one you just ran — if macOS objects at this point while your checksum matched, you have an intact copy of something Apple will not vouch for, which is a distinct problem rather than a corrupt download.

One aside worth knowing, because it explains where some published values live: a Homebrew cask pins a SHA-256 for the file it describes, and plenty of casks pin nothing at all, because the vendor's URL always serves whatever is newest. Either way the value is only as good as whoever wrote the cask, and you are left with no record of which build actually landed on your disk.

No web page can settle this one, here or anywhere: a .dmg is bytes sitting on your disk, and reading them is what an app on the Mac is for. The free SHA-256 generator on this site hashes text you type, which is the right tool for a value somebody pasted into a ticket and no use at all on a disk image. For the image itself, Verify takes the file and the published hex and answers with a seal and a sentence; Files is the side you want when the digest is going into a record rather than into a comparison.

Why two DMGs of the same app rarely match

Two downloads of the same posted file always produce the same digest. Two builds of the same application almost never do, and that catches people out constantly.

Making a disk image writes creation timestamps into it, and the result depends on the compression settings, the filesystem layout and the order files were added. A developer who rebuilds from identical source the next morning gets a byte-different .dmg with an entirely unrelated digest. So a hash quoted in a forum post about version 3.2.1 can fail against a perfectly legitimate 3.2.1 that was re-uploaded, and a digest you recorded last week can fail against today's download from the same unchanged URL.

The practical rule: only ever compare against a digest published for the specific file you downloaded, by the people who built it. Everything else is guesswork with extra steps. What to do when a checksum does not match sorts the innocent explanations from the alarming ones.

Recording the digest of a build you trust

Once an image has passed both checks, its digest stops being something you compare and becomes something worth keeping. Drop the .dmg into the Files tool and the row carries the name in bold, the folder beneath it, the size, and the digest middle-truncated; the copy button at the end of the row puts the full value on the clipboard, and the chevron next to it expands that one file into all eight algorithms if you also need the digest somebody else's tooling expects. The image is read once either way.

For more than one build, the export button writes the rows out as a text file — one line per file, digest first, then two spaces, then the name:

e57dc1f5332fd3aba24fdde531baef311df50a90de477791f20b625d0547b13f  SomeApp-3.2.1.dmg
bf7d5c76fbbfaca968f12cc2c8d9a5d45292bb0c3c263b4cddfc03bb9a08deca  SomeApp-3.2.2.dmg

Two lines in that shape are what separates “the build I tested” from “a build with the same version number”, which is exactly the distinction a code signature cannot draw for you. Exporting a checksum manifest covers what ends up in the file, what does not, and where to keep it.

Months later the check runs in the other direction. Paste the recorded hex into the Verify tool's Against a Checksum mode and the image you kept either matches it or does not. If you still have both copies — the one in your archive and a fresh download from the same URL — switch to File vs. File, drop one into each well, and the verdict is a green seal and a sentence instead of two rows of hex to read across. The swap control between the wells exists so that you can put them the right way round in your head without dragging them again.

Hashing what is inside the disk image

Once the image is mounted, a volume appears in the Finder and the application sits inside it. Hashing that application will never give you the disk image's digest — they are different bytes, and one of them is not even a file.

That last part is the detail people trip over. A .app is a directory, not a file. There is no single digest for an application bundle; what you get is one digest per file inside it, which is still useful for comparing an installed copy against a known-good one, but it is a list rather than a fingerprint. Hashing a whole folder explains why a folder has no one digest and how to work with the per-file result.

Plenty of Mac apps ship as a .zip instead of a disk image, and those behave differently again: the archive carries its own CRC32 for each entry, which answers a question about unpacking rather than about the download. Verifying a ZIP archive untangles the two checks.

Troubleshooting

macOS refuses to open the app and calls it damaged

Read it together with your checksum result, because the two together localize the fault. If the digest matched the published one, the bytes are right and the problem is the signature, the notarization or the quarantine state — a re-download will change nothing. If the digest did not match, you have a corrupt or incomplete file and a re-download is exactly the fix.

The developer publishes no checksum anywhere

Common, and not the disaster it sounds like for Mac software specifically, because notarization and Developer ID signing carry real weight here in a way they do not on other platforms. Download from the developer's own domain over HTTPS, and note the developer name macOS reports rather than clicking straight through it. Then compute the digest yourself in the Files tool and keep it, so that the next copy of that build has something to be compared against and you are not relying on your memory of a version number.

The digest matches a version I did not expect

You probably have more than one copy in Downloads. A browser that finds an existing file appends a number rather than overwriting, so the file you dragged in may be the one from six weeks ago while the new one sits below it with a (1) in the name. Sort the folder by date added and check the size in the drop well before you trust either.

I hashed the mounted volume instead of the image

Then you hashed something the developer never published a digest for, and no amount of retrying will make it match. Eject the volume, go back to the .dmg in Downloads, and hash that. The name is the giveaway: the thing you want ends in .dmg and sits in a folder, not on a mounted volume.

The published value is only 40 characters

That is SHA-1, and you can still use it — you are comparing against their value, so you need their algorithm. It is weaker evidence than a SHA-256 would be, for reasons the case against SHA-1 sets out, and it is worth asking a project that still publishes only SHA-1 to move on. A 32-character value is MD5 and the same reasoning applies more forcefully.