How to hash an ISO file on Mac
There is a 5 GB ISO in your Downloads folder and a USB stick you are about to overwrite with it. Dropping the image and the publisher's SHA-256 into Rocket Hash settles it in under a minute — but the check is only worth something if the value you compare against came from the right place. So most of this page is about finding the publisher's real checksum and reading it correctly.
An ISO is the one file almost everybody checks, because it is the one file where being wrong is expensive. A corrupt image writes to a USB stick perfectly happily and then fails twenty minutes into an install, or installs something subtly broken that you spend a weekend diagnosing.
The check itself is quick. Hand the ISO to the Verify tool in Against a Checksum mode, paste the line the publisher lists for that exact image, and read the sentence underneath — you get a match or no-match verdict rather than 64 characters to compare by eye. Do it before you write the stick, not after.
The part worth slowing down for is where the checksum comes from. A value you found on a forum, a mirror's own copy, or a tutorial from 2019 will produce a confident mismatch and teach you nothing. So the list comes first here: where the publisher's own copy of it lives, how to pick your line out of a dozen, and what the signature beside it is for. If the distribution is Linux specifically, verifying a Linux ISO goes deeper on the GPG half.
Writing an image to a USB stick takes minutes and tells you nothing about whether the image was sound. Hashing first means a bad download costs you one re-download instead of a failed install and an hour of suspicion about your hardware.
Where the publisher's checksum actually lives
Not on the download button. Nearly every project that ships ISOs puts the checksums in the same directory as the images themselves, in a plain text file, covering every image in that directory at once.
- Ubuntu and Debian. A file called
SHA256SUMSin the release directory, with a detached signature beside it —SHA256SUMS.gpgorSHA256SUMS.signdepending on the project. Debian often publishesSHA512SUMStoo. - Fedora. One checksum file per image set, clear-signed, so the digests and the signature live in the same file rather than in two.
- Arch and the smaller projects. Usually printed on the download page itself, sometimes only inside the release announcement or the torrent.
- Microsoft. Inconsistent. Some ISO download pages list a SHA-256 next to each image and some publish nothing at all, in which case there is no published value to compare against and no amount of hashing will invent one.
Two rules about that file. Get it over HTTPS from the project's own domain, not from the mirror that served you the image — a mirror that handed you a bad file will happily hand you a checksum to match it. And make sure it is from the same release directory, because a point release reuses the series name while changing every byte of the image.
How to read a SHA256SUMS line
The format comes from the Unix tools that generate it, and it is three fields on one line with no header and no commas.
| Part of the line | What it is | Where it goes wrong |
|---|---|---|
| The digest | 64 hexadecimal characters, lower case | If it is 128 characters you have opened a SHA-512 list and will need that algorithm instead |
| The separator | A space, then either a second space or an asterisk | The asterisk means binary mode. It is part of the format, not part of the file name, and not a typo |
| The file name | Exactly as the publisher named it | Your browser may have renamed your copy, which breaks automated checking and nothing else |
One list covers the whole directory, so a single SHA256SUMS may hold a dozen lines: desktop and server, amd64 and arm64, this point release and the last one. Matching your file against the wrong line is far and away the most common cause of an ISO “failing” verification. Find the line whose file name is character-for-character the image you downloaded, architecture included — on an Apple Silicon Mac you very likely want arm64 for a virtual machine and amd64 for a stick that has to boot a PC.
What a shasum file is covers the format in full, including the variants with a header block and the ones that list relative paths.
Check the ISO against the published value
-
Open the publisher's checksum file
Go to the same directory you downloaded the image from and open the checksum file in your browser. It is plain text, so it renders as a wall of hex — that is what it is supposed to look like.
-
Confirm the download is complete
Before hashing anything, compare your file's size in the Finder against the size listed on the download page. A truncated ISO is the most likely explanation for any mismatch you are about to see, and the size tells you that in one second instead of five minutes.
-
Copy the line for your image
Select the whole line for your exact file name — digest, separator, name and all. There is no need to reduce it to the digest on its own, and keeping the name attached is a cheap confirmation that you took the line you meant to.
-
Hand both to the Verify tool
Drag the ISO into the drop well or pick it with the Replace… link, then paste the line you copied. The algorithm is worked out from the length of what you pasted, so there is nothing to choose: 64 characters is read as SHA-256, 128 as SHA-512.
-
Read the verdict, then write the stick
A 5 GB image streams past in a few seconds on internal storage and rather longer from a USB drive. A green seal and a sentence means the bytes are the publisher's bytes and you can write them with confidence; anything else means stop and read the mismatch section below before you overwrite anything.
If the verdict comes back negative, the thing to repeat is the download rather than the comparison. Hashing is deterministic: a second pass over the same file returns the same 64 characters, so running it again proves nothing. Fetch the image a second time instead, from the project's own server rather than the mirror that served the first copy, and put the two files side by side in the Verify tool's File vs. File mode. Two downloads that agree with each other and disagree with the published list suggest the list is for a different point release; two that disagree with each other point at your connection. Comparing two files directly covers what that mode reads and what the seal underneath it means.
What the checksum proves, and what the signature adds
A matching digest proves one thing precisely: the bytes on your disk are the bytes the list describes. It proves nothing about who wrote the list. If an attacker controls the page, they serve you a modified ISO and a matching checksum, and your verification passes cheerfully. That is why the signature file next to the list exists — it binds the list to a key you can obtain independently, which is the step that lifts the claim from “these bytes are unaltered” to “these bytes are theirs”.
This is also where the algorithm genuinely matters, and the reasoning is finer than “MD5 is broken, use SHA-256”. Two different properties are in play:
- Collision resistance is the difficulty of finding any two inputs with the same digest. MD5 lost it in 2004, and by 2006 one collision took about a minute on a laptop. SHA-1 lost it publicly in 2017, when the SHAttered work produced two different PDFs sharing one SHA-1 digest.
- Second-preimage resistance is the difficulty of starting from a file that already exists and building a different file with the same digest. Nobody has broken that for MD5 or SHA-1; it remains computationally out of reach.
So an MD5 a project published years ago for an ISO that already existed is not worthless — forging a bootable image to match it is still infeasible. What it cannot survive is an adversary involved before publication, who can produce a pair of files with one digest and get the innocent one blessed. Since you usually cannot tell which situation you are in, take SHA-256 when it is offered and treat a lone MD5 as weak evidence rather than proof. Whether MD5 is still safe works through the cases where it is genuinely fine.
What happens while a 5 GB image is hashing
In the Files tool an image this size is streamed once from beginning to end and never held in memory: the footprint stays flat at roughly 16 MB whether the file is 700 MB or 12 GB. Ask for more than one algorithm and it is still read exactly once — every digest comes out of that single pass, so checking a SHA-256 and a SHA-512 against a page listing both costs no more than checking one.
Live throughput and an estimated time remaining appear while that happens, and the throughput figure is the most useful diagnostic on screen. SHA-256 runs at roughly 2 GB/s on Apple Silicon, so anything well below that is the storage talking rather than the algorithm: a few seconds off an internal SSD, closer to a minute from a USB 3 disk, ten from a network share. A number far lower than the drive should manage points at the drive or the cable — why hashing is slow works through the causes.
A run in that tool can also be paused mid-image and resumed from the exact byte it stopped at, which is the difference between interrupting a verification and starting it over — and that is precisely the ISO case: three large images on one slow external drive, and something else that needs the bus. Hashing a large file has the rest of the behavior.
After you write the USB stick
People reasonably try to verify the stick afterwards, and then find that hashing it gives an answer matching nothing. The stick is not a copy of the file. Writing an image puts the ISO's bytes at the start of a raw device that is larger than the image, so reading the whole device back gives you the image plus however many gigabytes of whatever was there before.
There is also nothing useful to point a file-hashing app at, since what you would have to measure is a raw device rather than a file. That is the reason the order matters: check the image while it is still an image, and the write becomes the only step left that can have gone wrong.
That leaves the stick itself: if an install fails after a verified image, try a different port, a different stick, or writing it again. A green seal on the ISO has already taken the download out of the list of suspects.
Troubleshooting
The digest does not match the published one
In order of likelihood: the download truncated, you are on the wrong line of the list, or you have a different point release from the one the list describes. Check the file size against the download page first, because it eliminates the most common cause without hashing anything. What to do when a checksum does not match runs through the rest in order.
The list has a dozen lines and I cannot tell which is mine
Match on the file name, not on position, and read the whole name rather than the first word of it. Desktop against live-server, amd64 against arm64, and 24.04.1 against 24.04.2 are all separate images with entirely unrelated digests. If your local copy has been renamed, the publisher's name is the authority and yours is the thing that changed.
My file is called .iso.part or has a (1) in the name
A .part or .crdownload file is a download still in progress and its digest describes a fragment. A (1) means your browser found an existing file with that name, which usually means you already have a complete copy sitting beside the new one — make sure you are hashing the one you intend to write.
The hex looks the same but the verdict says no
Count the characters before you blame the file. A non-breaking space out of an HTML table, a line break the page inserted mid-digest, or a zero-width character will all defeat a comparison while looking like nothing at all. Copy the line again from the raw text file rather than from a rendered page, and make sure what you end up with is 64 hex characters and nothing besides. Identifying a checksum by its length has the full table if the count is surprising.
Nobody published a checksum at all
Then you cannot verify the download, and it is better to know that than to pretend otherwise. What you can still do: download over HTTPS from the vendor's own domain, check whether a signature or a package manager with pinned digests offers the same image, and compute the digest yourself now — one row in the Files tool, copied out and kept — so that a second copy fetched next month can be compared against the first. Two independent downloads agreeing is weak evidence, but it is not nothing.
It verified but the installer still will not boot
Then the download was never the problem. A matching digest clears the image and points the finger at everything downstream: the write to the stick, the stick itself, the port, the boot mode, or Secure Boot settings on the target machine. Rewrite the stick before you re-download the ISO — you already have proof that the ISO is fine.
Frequently asked questions
Do I need to mount the ISO to check its checksum?
No, and you should not. Hashing reads the image file as a stream of bytes from beginning to end; mounting it asks macOS to interpret those bytes as a filesystem, which is a different operation and an unnecessary one. Leave the image as a file in Downloads and hash it there.
Where do I find the SHA-256 of an Ubuntu ISO?
In the same directory on the project's own server that you downloaded the image from, in a plain text file named SHA256SUMS, with a detached signature file beside it. That one list covers every image in the directory, so find the line whose file name matches your download exactly — desktop or server, amd64 or arm64, and the right point release.
Why does my USB stick not match the ISO's checksum?
Because the stick is a device, not a copy of the file. The image occupies the first few gigabytes of a drive that is larger than it, so hashing the whole device hashes the image plus whatever follows it. There is no way round that from an app that hashes files, since a raw device is not a file — which is why the check belongs before the write. Verify the ISO, then test the stick by booting it.
Is MD5 good enough for verifying an ISO?
It is weak evidence rather than proof. MD5 collisions — two files sharing one digest — have been public since 2004 and a minute of laptop time since 2006, but nobody can take an ISO that already exists and build a different working image with the same MD5, because second-preimage resistance has not fallen. So an old published MD5 still catches corruption and casual substitution; it fails against anyone who could influence the file before the digest was published. Use SHA-256 whenever it is offered.
The page lists both SHA-256 and SHA-512 — which should I use?
Either. They are two different fingerprints of the same bytes, and matching one is sufficient; there is no scenario where one matches and the other does not unless you have the wrong file or the wrong line. SHA-256 is 64 hexadecimal characters and SHA-512 is 128, so whichever you paste identifies itself by length.
Can I verify a Windows ISO on a Mac the same way?
The arithmetic is identical — an ISO is just a file, and your Mac does not care what is inside it. The obstacle is publication rather than platform: Microsoft lists a SHA-256 beside some images and none beside others, and where no value is published there is nothing to compare against. Insider and volume licensing downloads are the ones most likely to show a digest.
How long does hashing a 5 GB ISO take?
A few seconds on a recent Mac's internal SSD, where the limit is how fast the drive can hand over the data rather than the algorithm. From a USB hard disk, closer to a minute. Either way it is shorter than the time you would spend writing the image to a stick and discovering the problem the hard way.