How to see hashing speed and time remaining on Mac
While a file streams past, Rocket Hash shows you the rate it is reading at and an estimate of the time left. Here is how to read both, how to turn a rate into a wait with one division, and why the number on screen is almost always describing your disk rather than the algorithm.
A progress bar with no number on it is almost useless. What you want to know is whether this is a ten-second wait or a lunch break, and that answer comes from two figures the Files tool puts on screen while a run is in progress: the rate the file is actually streaming at, and an estimate of the time left. One is measured, one is predicted, and the difference between them explains most of the confusion.
The arithmetic, if you want it before anything else, is one division. A file's size in gigabytes, times a thousand, divided by the rate in megabytes per second, gives you seconds. A 10 GB file at 120 MB/s is about eighty-three seconds, and no amount of faith in your CPU changes that.
This page is about reading those numbers and trusting the right one. If the number you are looking at is disappointing rather than merely informative, why hashing is slow on a Mac is the page that fixes it.
SHA-256 runs at roughly 2 GB/s on Apple Silicon. Only an internal SSD or a Thunderbolt NVMe enclosure supplies data at anything like that rate, so for every other drive the figure on screen is a measurement of the storage rather than of the algorithm.
The two numbers mean different things
Throughput is a fact. It is bytes of file divided by seconds of wall clock, sampled over the recent past, and it describes what has already happened. If it says 480 MB/s, then 480 MB of your file went past in the last second.
Time remaining is a guess, and it is a guess built on one assumption: that the rest of the job looks like the part already done. For a single large file on one disk that assumption is excellent and the estimate is boringly accurate. For a folder of mixed sizes it is close to worthless at the start, because the average so far tells you almost nothing about whether the 9 GB video is second in the queue or last.
The status bar along the bottom carries the other half of the picture, in plain counts rather than rates: what is in the queue at one end — 1 file · 2 kB — and how much of it is done at the other, as ✓ 1 hashed. On ninety thousand files that count is the number you actually watch. On one enormous file it barely moves, and the throughput figure is the only thing telling you anything.
Measure your own machine in two minutes
Published figures are averages of hardware you do not own. Two minutes with a file you already have will tell you what your Mac and your disk do together, which is the only number worth planning with.
-
Pick a file big enough to measure
Several gigabytes, ideally an ISO or a video you already have. Anything under about 100 MB finishes before the rate has anything to average, so you will get a number that bounces and then vanishes. Use a file on the disk you actually want to know about.
-
Know what the figure covers
Set the Algorithm control to SHA-256 if you like, but know what it does: it decides which digest the row shows you, not how much arithmetic happens. The file is read once and all eight digests come out of that pass, so the throughput you are about to read is always the all-eight figure. There is no single-digest mode to set it against, which is why step four compares one disk with another instead.
-
Start it and let the rate settle
Drag the file in and watch. The first second or two is startup noise; after that the figure steadies into something representative. Write it down. If it climbs steadily rather than leveling off, you are probably reading a file that is partly in your Mac's memory already — more on that below.
-
Turn the rate into a time
Divide. Gigabytes times a thousand, over megabytes per second, gives seconds — so 500 GB at that 120 MB/s is around 4,200 seconds, or a bit over an hour. Then hold the figure you wrote down against the row for your storage in the table below. Landing anywhere near it means the disk set the pace, which is the usual answer. To settle it, copy the same file to the internal SSD in the Finder and hash it there: a rate that jumps several times over tells you the arithmetic was never the limit, and one that barely moves tells you it was.
What a realistic rate looks like
These are representative sequential read figures, not promises, and the spread within each row is wide. The third column is the thing you actually care about.
| Where the file lives | Typical read rate | A 10 GB file takes |
|---|---|---|
| Internal Apple SSD | Several GB/s — here the algorithm is the cap | Around five seconds |
| Thunderbolt NVMe enclosure | 1.5–2.8 GB/s | Under ten seconds |
| USB 10 Gbps portable SSD | 800–1,000 MB/s | Ten to twelve seconds |
| USB portable hard disk | 100–130 MB/s | Around a minute and a half |
| UHS-I SD card | 40–95 MB/s | Two to four minutes |
| Gigabit Ethernet share | 110 MB/s at best | A minute and a half, if nothing else is using the wire |
Notice what is missing: a row for the algorithm. At roughly 2 GB/s, SHA-256 on Apple Silicon is faster than every line in that table except the top two. Hashing files on an external drive covers why the bus speed printed on the box so rarely predicts which of those rows you are in.
When the algorithm does become the limit
There is one place the arithmetic wins the race to be slowest, and it is your fastest storage. A single SHA-256 at 2 GB/s is already in the same range as a modern Apple SSD or a Thunderbolt NVMe enclosure, and Rocket Hash computes all eight digests from every read, so on that hardware the order flips outright. The file is still read exactly once — that is the point of single-pass streaming, and it is why eight digests do not mean eight trips across the disk — but eight digests is eight times the arithmetic on the same bytes, and no amount of streaming cleverness changes that.
It almost never matters, and there is nothing to decide either way: every digest is computed during the single read, which is the right trade, because a second pass over a 400 GB file would cost vastly more than a little extra computation during the first. Which algorithm you pick makes less difference than people expect on modern hardware, and the SHA-256 versus SHA-512 comparison has the surprising part of that story.
Why a folder of small files is slower than one big one
Rate is measured in bytes per second, and small files spend their time on things that are not bytes. Every file has to be located, opened, permission-checked and closed, and on a queue of fifty thousand documents that overhead is the job. You can watch it happen: the same 10 GB arrives in seconds as one file and takes minutes as a hundred thousand small ones.
So judge a batch by the hashed count climbing rather than by the throughput figure, which will look embarrassing and is telling you the truth about a workload it was not designed to describe. Hashing many files at once goes into what that queue does at six figures.
macOS keeps recently read data in memory, so hashing the same file twice in a row can produce a rate your disk cannot physically achieve. Benchmark with a file you have not touched since you booted, or treat the first run as the real one.
Working out whether to wait
Once you have a rate you trust, the decision is arithmetic rather than patience. Under a minute: wait. A few minutes: start it and read something. Over about twenty minutes: plan for it, because that is long enough for a sleep, a disconnect or a change of mind to cost you the lot. A run that long can be paused and resumed from the byte it stopped at, which turns an hour-long job into something you can fit around the rest of the day.
For files measured in hundreds of gigabytes, the size stops being an interesting variable at all. The job is one sequential read at the rate you just measured, so there is no setting to tune and no trick to find — only the decision of whether to start it now or at the end of the day. Hashing a very large file covers planning a run at that scale.
Troubleshooting
The rate looks fine but the job is taking forever
Check what is in the queue. A high throughput figure with a slow-moving hashed count means one very large file is in progress; a low figure with a fast-moving count means thousands of small ones. Both are normal, and they want different numbers watched.
The time remaining said two minutes and it took ten
The estimate extrapolated from the files it had already seen, and the queue was not uniform. This is inherent rather than a defect: no estimator can know that the last item is a 60 GB disk image until it gets there. For mixed batches, take the first estimate as a lower bound and watch it converge.
The rate drops part way through a single file
On a spinning disk, the outer tracks are genuinely faster than the inner ones, so a long sequential read slows down as it works inward. On an external SSD in a cheap enclosure, sustained reads can also throttle as the controller heats up. Neither is anything to do with the hashing; both show up in any large file copy from the same drive.
The throughput figure is not on screen
It describes work in progress, so it has nothing to say once a run has finished, been paused or been stopped. If a run ends faster than you can read the number, the file was too small to measure — pick something multi-gigabyte if you are trying to benchmark.
Everything is slower than these figures suggest
Work down the list of usual suspects rather than guessing: a network share, a security product filtering every read, Spotlight indexing the same volume, a nearly full disk, or a drive that was never as fast as its box claimed. Why hashing is slow on a Mac has a one-minute test that separates them. The cheapest cross-check is the Finder: copy the same file off the same volume and watch that rate instead. If the copy crawls too, you are measuring the drive rather than anything the hashing is doing, and no algorithm choice will rescue it.
Frequently asked questions
How long does it take to hash a 1 GB file on a Mac?
On an internal Apple SSD, under a second. On a USB portable hard disk, around eight to ten seconds. Over a gigabit network share, about nine seconds at best. The algorithm is not what varies — SHA-256 runs at roughly 2 GB/s on Apple Silicon — so the answer is set by how fast the storage can hand over a gigabyte.
Does hashing with all eight algorithms take eight times as long?
No, and it is not something you choose: the file is read once and all eight digests come out of that pass. On anything slower than a fast internal SSD the read is the slow half, so the other seven are close to free. On a very fast internal drive the arithmetic can become the limit, and eight digests are measurably slower than one would be — still nowhere near eight times.
Why is the estimated time remaining so inaccurate?
Because it extrapolates from what has already been hashed, and a queue of mixed file sizes breaks that assumption. The estimate is reliable for one big file on one disk and unreliable for a folder where the largest item happens to be last. Watch it converge rather than trusting the first figure it shows.
Is hashing limited by the CPU or the disk?
Almost always the disk. SHA-256 at roughly 2 GB/s on Apple Silicon outruns every hard disk, every SD card and every network share by a wide margin. The exceptions are an internal Apple SSD and a Thunderbolt NVMe enclosure, which read in the same range — there a single digest is roughly a tie, and the eight the app computes from one read make the arithmetic the slower half.
Why was the second run faster than the first?
macOS keeps recently read data in memory, so the second pass over the same file can be served partly from RAM at a rate the drive itself cannot reach. For an honest measurement, use a file you have not touched since booting, or take the first run as the real number.
Can I use hashing to benchmark a drive?
It is a decent sequential read test, and an unusually safe one, because hashing never writes a byte. Hash a multi-gigabyte file and, on anything short of the fastest internal SSD, the throughput figure is essentially your drive's read speed. What it will not measure is random access or write performance.
Why does hashing a folder of small files report such a low rate?
Because most of the time goes on per-file work rather than on bytes: locating, opening, permission-checking and closing each file. The same total volume is dramatically faster as one large file than as a hundred thousand small ones. For batches, judge progress by the count of files hashed rather than by the throughput figure.