How to hash multiple files at once on Mac
Three hundred files, from four different places, and you need a digest for each one. Select them, drag the whole selection into Rocket Hash at once, and they stream through one after another while two counters in the status bar tell you how much is queued and how much is done — then the lot comes out as a single list.
The job arrives in a few recognizable shapes. A photographer has handed you a card full of raw files and you want a record of each one before the card gets wiped. A release is going out with eleven artifacts in it. You are about to retire a drive and want to know that every file you copied off it arrived intact. In all of them the work is the same and the quantity is the only interesting thing about it.
This page is about running a batch: getting a selection in, choosing the algorithm once rather than three hundred times, reading the two numbers in the status bar while it works, getting the machine back if the run is long, and ending up with one file that holds the whole result.
If your files all live under one folder, drag the folder rather than its contents — hashing a folder covers what that produces and the hidden files you will collect along with it. A batch of one needs none of the queue mechanics below — start at hashing a single file instead.
Click the first file, shift-click the last, and drag the whole selection into the window in one go. Dropping files in one at a time works and is a waste of your afternoon.
What a batch actually does
Files go into a list and are read one after another, not all at once. That is deliberate, and it is the right design: hashing is limited by how fast the disk can hand over bytes, so reading four files simultaneously from the same drive makes all four slower and the total no faster. Each file gets its own row with its own digest, and the run moves down the list.
Nothing is held in memory. Each file is streamed past the algorithm and discarded, which is why memory stays flat at roughly 16 MB whether the batch is eleven files or a hundred thousand, and why a batch containing a 200 GB image is no more demanding than one containing none. The list itself is the only thing that grows, and it copes with six figures of files.
Run a batch
-
Select the files in the Finder
Click the first, then shift-click the last for a run of files, or hold ⌘ and click to pick out a scattered handful. Then drag the whole selection into the Files window at once. Nothing cares how many you grabbed; the drag that carries eleven files carries eleven thousand the same way.
-
Add the rest from wherever it lives
A batch rarely comes from one place. The add (+) button in the toolbar opens a panel to pick up another group, and a second drag from a second Finder window does the same thing — the list holds everything you have given it, from as many volumes as you like. The reset button is how you empty it and start over, which matters when you are about to export and want only the files you meant.
-
Set the algorithm once
Put the Algorithm control on the digest the exported list should carry. Every file is read once and all eight algorithms come out of that pass, so this settles the list rather than the work. One algorithm across the whole batch is what makes the result checkable later — a list with mixed algorithms in it cannot be verified by anything, because verifying means recomputing with the same function and nothing can tell which function a given line came from.
-
Read the two counters
The status bar along the bottom has a number at each end, and they answer different questions. On the left is what is in the list — files and total bytes, in the form
1 file · 2 kB. On the right is how far through it has got, in the form✓ 1 hashed. While a batch runs, the distance between those two is the work remaining; when it finishes, the fact that they agree is your completeness check. They are also where you find out that one of your eleven thousand files never got read. -
Pause if you need the Mac back
A long run can be paused mid-file and resumed from the exact byte it stopped at, which is not the same as starting that file again — on a 60 GB image the difference is half an hour. It can also be stopped cleanly, leaving the rows that finished intact and readable. Pausing and resuming goes through what survives each one.
-
Export the whole list
Do not copy three hundred digests by hand. The export button writes the batch out as a
shasum-compatible manifest — one line per file, digest and path — which is the form every other tool on every platform already knows how to read. Exporting a manifest covers where to keep it and what to send with it.
Why many small files take longer than one big one
The throughput figures quoted for hashing — roughly 2 GB/s for SHA-256 on Apple Silicon — describe a long sequential read. A batch of tiny files never gets near them, because the cost of opening a file, finding it on disk and closing it again is paid per file and has nothing to do with its size. Sixty thousand 200 kB thumbnails and one 12 GB disk image hold about the same number of bytes; the thumbnails take considerably longer.
| The batch | What limits it | What to expect |
|---|---|---|
| A dozen large files on an internal SSD | Disk bandwidth | Close to the best figure your drive can do |
| Five hundred photos, a few MB each | Mostly bandwidth, some per-file cost | Quick, and the counter climbs visibly |
| Sixty thousand small files | Per-file overhead | Much slower than the byte total suggests |
| Anything on a network share | Round-trip latency, per file | The worst case by a wide margin — copy it locally first |
The live throughput reading is how you tell which of those you are in. A rate well below what the drive can manage, on a batch of small files, is normal and not a fault; the same rate on one large file means something else is wrong. Reading the speed and the time remaining covers what to do with the number.
Choosing an algorithm for a big batch
The temptation with a large batch is to reach for something fast, and on modern hardware that temptation is mostly imaginary — SHA-256 has CPU instructions behind it and the disk is the bottleneck anyway. But the reasoning is worth having straight, because the two legacy algorithms fail in a specific way that people consistently misread.
CRC32 is the one that will actually bite you in a batch. It produces 8 hexadecimal characters, which is 32 bits, which is about four billion possible values. Queue a hundred thousand files and there is roughly a two-in-three chance that two unrelated files in the set share a CRC32 — by accident, with nobody trying. It was designed to catch transmission errors in a single transfer, and for that it is excellent. As an identity for files, at this scale, it is not usable.
MD5 and SHA-1 fail differently. Accidental collisions are not their problem: 32 and 40 hexadecimal characters are enormous spaces, and two files you did not construct on purpose will not collide. Their problem is constructed collisions. Two different files with the same MD5 were first published in 2004, and the same attack now takes seconds on a laptop. The first public SHA-1 collision came in 2017 — the SHAttered result, two different PDFs with one SHA-1 digest.
MD5 and SHA-1 have lost the first — nobody can stop you building two files that share a digest. They have not lost the second: there is still no way to take a digest and work backwards to a file that produces it. That is why an old MD5 manifest still reliably detects a corrupted copy, and still cannot prove a file is the one you were promised.
So the question to ask of a batch is who made the files. Your own photographs, your own exports, your own backup: MD5 will faithfully tell you whether a copy arrived intact, and whether MD5 is still safe makes the fuller case. Files that came from outside, or a list you might one day have to defend: SHA-256, and no real cost for choosing it.
What to do with a thousand digests
Nobody reads them, and a batch result you only look at once was barely worth running. Two things are worth doing with it while the list is still in front of you.
- Scan for repeats. Two rows with the same digest are two copies of the same bytes, whatever their names and dates claim — which is the whole basis of finding duplicates by hash, and it falls out of a batch you ran for some other reason entirely.
- Compare it with the list the files came with. If somebody shipped a manifest alongside the files, your job was never to read digests but to line two sets of them up — checking files against a manifest is that procedure.
What the exported list looks like
Here is what is inside that file. One line per file, the digest first, then two spaces, then the path it belongs to — four artifacts out of a release look like this.
5f3c7b0a9d41e6a8c2b75d10ef38a47c9b6e2d5f1a08c743be9d21f6a4c8b3e7 myapp-2.4.1-macos-arm64.zip
2a9e4c18b7d05f3ea61c8b42d79f0e53a4c6b1d8f205e97a3c4b6d8e0f12a357 myapp-2.4.1-macos-x86_64.zip
c7b1d4e0a93f58c26b0d7e1a4f8c35b9072e6d1a8c4f03b5e7d29a16c0b83f4d myapp-2.4.1-linux-amd64.tar.gz
8e0a3c5719d2b46f08a1c3e5d79b02f4a6c8e0b2d4f68a0c2e4b6d80f1a3c597 release-notes.mdTwo things about it matter later. Nothing in the file records which algorithm produced the digests — 64 characters narrows it to SHA-256 or SHA3-256 and no further, which is why the convention is for the name to carry the answer: SHA256SUMS, not checksums.txt. And the digest is the durable half of each line while the path is not, so moving the files leaves every path stale and every digest still correct. What a SHA256SUMS file contains reads the format line by line, including the variant that puts an asterisk before the path.
Where it then goes depends on why you ran the batch. Beside the data, if this is an archive you will open again in five years. Into the repository, if the files are a release — checksums for a release covers what to publish. If one person needs to confirm one file, send that digest with its algorithm named rather than the whole list, which is what sharing a checksum covers.
Troubleshooting
The file count is not the number I selected
A count higher than expected usually means something in the selection was a folder, and folders expand into every file underneath them — including the hidden ones the Finder was not showing you. A count lower than expected is the direction worth worrying about: it normally means an item could not be read, which on a modern Mac is a permission gate rather than a fault, and the files most often gated are the ones on a mounted volume or in another user's home folder.
It is far slower than the total size suggests
Count the files, not the bytes. Tens of thousands of small files are a per-file workload and will never reach the rate a single large file does. If the batch is on a USB drive, an SD card or a share, that effect multiplies — and on a network share it multiplies brutally, because every file costs a round trip before any of its bytes arrive.
I need the Mac back before the batch finishes
Pause it. A paused run resumes from the byte it stopped at rather than the beginning of the file, so there is no penalty for taking the machine back for twenty minutes. If you need to abandon the run instead, stop it and export what has finished — a partial manifest covering eight hundred of a thousand files is worth keeping, and you can hash the remainder separately later.
The Mac went to sleep during a long run
A batch that will run for hours needs the machine awake for those hours, and on battery macOS will make its own decisions about that. Plug in before you start anything long, and check the sleep settings in System Settings if a run keeps stalling overnight. An external drive that spins down or unmounts itself mid-batch produces the same symptom from a different cause.
Two rows show the same digest
They are the same file, byte for byte, under two names or in two folders. This is not an error and it is frequently the most interesting thing a batch tells you — it is how you find the photo you imported twice and the archive you have three copies of. If the two digests are CRC32 rather than SHA-256, treat it as a coincidence worth confirming with a longer algorithm before you delete anything.
Frequently asked questions
How do I hash multiple files at once on a Mac?
Select them all in the Finder — click the first, shift-click the last — and drag the whole selection into the Files list in one go, or use the add (+) button to pick them from a panel. They are read one after another rather than all at the same time, because the disk is the bottleneck and parallel reads from one drive make every file slower without finishing the batch any sooner. One row comes back per file, and the export button turns the whole list into a single text file.
How many files can I hash in one batch?
Six figures is routine: 100,000 files and more in one list. Memory use does not grow with the batch, because each file is streamed past the algorithm and discarded rather than loaded, so the practical ceiling is your patience and the speed of the disk rather than anything in the software.
Do all the files have to be in the same folder?
No. A batch can be assembled from several folders and several volumes — drag one group in, then another, or use the add button for each. This is the main reason to build a batch by selection rather than by dropping a folder: you get exactly the files you chose and nothing else.
Can I use different algorithms for different files in a batch?
You can see every algorithm for any individual file by expanding its row, but an exported list should use one algorithm throughout. A manifest with mixed algorithms cannot be checked, because checking means recomputing each line with the function that produced it and the line does not say which that was. Pick one — see which hash algorithm to use.
Why is hashing 50,000 small files slower than one huge file?
Because the overhead is per file, not per byte. Opening, locating and closing a file costs roughly the same whether it holds 4 kB or 4 GB, so a batch of small files spends most of its time on bookkeeping and never reaches the sustained read rate a large file does. On a network share the effect is much worse, since each file costs at least one round trip.
Is MD5 good enough for hashing a big batch of my own files?
For detecting corruption in files you created yourself, yes — MD5 reliably catches a copy that went wrong, and accidental collisions are not a realistic concern. It is not good enough when the files came from somewhere else, because MD5 collisions can be constructed deliberately — the first pair was published in 2004 and the attack now takes seconds. CRC32 is the one to avoid in a large batch outright, since a set of 100,000 files is likely to contain an accidental CRC32 collision.
What happens if I stop a batch halfway through?
The files already finished keep their digests, and the one in progress can be resumed from the byte it reached instead of starting over. You can export a partial list and hash the remainder later — a manifest covering part of a set is still a useful record, as long as you know which part it covers.