Why is hashing slow on my Mac?

Something is taking far longer than it should, and the obvious suspect is the hashing. It is almost never the hashing.

On Apple Silicon, SHA-256 manages roughly 2 GB/s. Outside your internal SSD, nothing in a normal Mac setup can supply bytes at that rate — not a USB drive, not an SD card, not a gigabit share, not a hard disk. So a slow run is nearly always a slow read, and the fix lives somewhere other than the algorithm you picked. There are six places it usually lives, and one test that separates them in about a minute.

If the number on screen is merely unfamiliar rather than disappointing, reading the throughput and time-remaining figures is the page that explains what each one measures and how to turn a rate into a wait. This page assumes you already know the number is bad and want to know why.

The one-minute test

Two numbers settle it, and the app puts the first on screen while it works: the rate a run is actually getting, against what that source is physically capable of. The gap between them is the diagnosis.

1. Read the rate the run is getting

   Add the file to the Files tool and watch the right-hand end of the status bar while it streams: live throughput, and the time remaining worked out from it. Give it ten seconds to settle, because the opening moment of a run goes on finding and opening the file rather than reading it. What the live rate and the estimate each measure is the longer version.

2. Compare it with what that source can deliver

   Find the row in the table below that matches where the file physically lives, not where its icon appears. A rate anywhere near that figure means the storage is the bottleneck, the arithmetic is keeping up with room to spare, and no change of algorithm will move it. Far below, and one of the first five causes has it.

3. Hash a local copy of the same file

   Copy the file to your internal SSD in the Finder, drop the copy into the window, and compare the two rates. A large jump means the source was the limit. No jump at all, on a Mac whose internal drive reads gigabytes a second, means something is inspecting every read the machine performs — cause four. The copy earns its keep either way: two matching digests prove it arrived intact, which is verifying a file after a transfer for free.

One caveat: macOS keeps recently read data in memory, so a file you hashed half an hour ago can report a rate its drive cannot physically reach. Take the first run as the real one.

What is actually slowing it down

In roughly the order these turn out to be the cause.

1. The file is not on the disk yet

iCloud Drive with storage optimization on, Dropbox, Google Drive and OneDrive all leave placeholders where the contents used to be. Reading one materializes it, which means the first read goes at the speed of your broadband and not your disk. The give-away is unmistakable: the rate matches your download speed, and the second run finishes almost instantly.

The fix is to make sure the material is genuinely local before you start — download the folder, or keep files you hash regularly outside synced folders altogether. A 50 GB run that silently becomes a 50 GB download is the worst version of this problem, because it also consumes your connection for an hour.

2. The file is on a network share

A share is the slowest place you can hash from, and not only because of raw bandwidth. Every read is a round trip, the protocol adds its own overhead, and the wire is shared with whatever else the office is doing. Gigabit Ethernet tops out around 110 MB/s on a good day; Wi-Fi is lower and far less consistent, and a single congested switch can halve it without warning.

Copy the file locally and hash the copy. That sounds like extra work and usually is not, because verifying the copy against the original's digest is a thing you wanted anyway — verifying a file after transferring it is the same operation with a purpose attached.

3. The drive is slower than its label

A USB-C port is not a speed, and the number printed on an enclosure is a ceiling nobody reaches. A 10 Gbps drive in a 5 Gbps port runs at 5 Gbps. A cable with no data pairs in it drops the link to USB 2 speeds, which is about 40 MB/s. A hub with a webcam and a display on it is sharing that bandwidth. A spinning disk reads its outer tracks about twice as fast as its inner ones, so one drive can hand you 200 MB/s at the start of the platter and 90 MB/s at the end. An SD card reads at 40–95 MB/s and that is simply what it does.

Plug the drive directly into the Mac with the cable it came with, start the run again, and watch whether the rate in the status bar changes. Hashing files on an external drive goes into which of those factors usually turns out to be the culprit.

4. Something is inspecting every read

Corporate antivirus, endpoint detection agents and data-loss-prevention tools install themselves in the path of file access, and every read your Mac performs goes through them for a decision. A hashing run is the most read-heavy thing you can ask a machine to do, so it is the workload that makes such a filter most visible — a job that should take two minutes can take twenty.

The tell is that copying the same file is also slow, and that Activity Monitor shows a security process using real CPU while your hashing tool sits nearly idle waiting for bytes. Be realistic about the fix: on a managed Mac this is not yours to switch off. What you can do is ask whoever runs it for an exclusion on the volume you work with, and say how long the job currently takes, which is usually the argument that lands.

5. Spotlight is indexing the same volume

A drive you have just attached for the first time gets indexed, and so does a volume after a macOS upgrade or a restore from backup. Indexing reads a great deal and competes with you for the same device. It finishes eventually, but on a multi-terabyte archive disk “eventually” can be hours.

The tell is in Activity Monitor's Disk tab: an indexing process reading steadily from the same volume you are hashing. Adding that volume to Spotlight's list of excluded locations in System Settings stops it, and for an archive or backup disk you never search by name that is a reasonable permanent choice. Leave your startup volume indexed, though: too much of macOS depends on it.

6. You are asking for more work than you think

This is the one case where the arithmetic really is the limit, and it has two shapes. On a fast internal SSD, a single SHA-256 is already roughly a tie with the drive, so the eight algorithms computed from that one read make the computation the slower half — the file is still read exactly once, but eight digests is eight times the arithmetic over the same bytes. The other shape is a queue of very small files, where the time goes on locating, opening, permission-checking and closing each one rather than on bytes, so the rate looks humiliating while the file count races along.

Neither is really a fault, and the second is not even a slowdown — it is the wrong measure. Take the eight digests as the price of never needing a second pass over 400 GB, and judge a large batch by the count of files finished in the status bar rather than by megabytes per second. Hashing many files at once covers what a six-figure queue does.

Things that are not the problem

Worth ruling out explicitly, because each of these gets blamed regularly.

• Your choice among the strong algorithms. On a 64-bit CPU, SHA-512 often runs faster per byte than SHA-256, which surprises everyone — see SHA-256 versus SHA-512. Either way the difference disappears behind the disk.
• Switching to MD5 to save time. It only helps if the arithmetic is what you are waiting for, and the comparison above has probably just told you it is not. It also costs you collision resistance for nothing.
• What is inside the file. A compressed archive, an encrypted disk image and a text file of the same size all hash at the same rate. Hashing reads bytes and has no interest in what they mean.
• Memory pressure. A streamed hash holds roughly 16 MB whatever the file size, so a 900 GB image is not what is making your Mac swap.

When it is going to be slow anyway

Sometimes the answer is that 6 TB at the 150 MB/s a hard disk in a USB enclosure actually delivers is eleven hours, and no diagnosis changes that. At that point the problem is not speed but survival: a run long enough to matter is long enough for a sleep, a dismount or a change of plan to cost you the lot.

So settle two things before you start rather than four hours in: plug the Mac into power, and stop it sleeping while you are away from it. An external drive that unmounts under a sleeping Mac takes the run with it, and a share that drops mid-file does the same.

A run that long is also a run worth being able to interrupt. Rocket Hash will pause mid-file and pick up from the exact byte it stopped at, which turns a three-hour commitment into something that fits around the rest of the day, and hashing a very large file covers planning at that scale.

Troubleshooting

It was fast yesterday and slow today

Three usual explanations: the file is in a different place than you remember, yesterday's run was reading from memory rather than from the disk, or a security agent updated itself overnight and is now doing more work per read. Copy the file somewhere else and time that instead — if a plain copy is slower than it used to be as well, the hashing was never the thing that changed.

It starts fast, then collapses to a crawl

Three candidates, in order. The opening stretch of the file was still in memory from an earlier read and the rest had to come off the disk. A cheap external SSD enclosure is throttling as its controller heats up. Or a hard disk has worked its way in from the fast outer tracks toward the slow inner ones. Copy the same file rather than hashing it: if the copy stalls in the same place, nothing about this involves hashing.

Even the internal SSD is slow

Then something else is using it. Check Activity Monitor's Disk tab for a Time Machine backup in progress, a Photos library being analyzed, a large Mac App Store download, or Spotlight reindexing after an update. Free space is a red herring here: a nearly full SSD slows writes far more than it slows the sequential read a hash performs.

Progress has not moved at all

That is a different symptom from slow. A read from a share that has gone away, or from an external drive that has spun down or half-disconnected, can block indefinitely rather than fail — nothing is slow, nothing is wrong with the arithmetic, the bytes simply are not arriving. Check the volume is still mounted in the Finder before you wait any longer.

A folder of documents reports a terrible rate

Expected, and not a problem to solve. Megabytes per second is the wrong measure for a queue of small files, because most of the work is not bytes. Watch the count of files completed instead; if that is climbing steadily, the run is healthy however bad the rate looks.

Frequently asked questions

Why is hashing a file so slow on my Mac?

Because the file is arriving more slowly than the algorithm can consume it. SHA-256 manages roughly 2 GB/s on Apple Silicon, which is faster than any external drive, SD card or network share, so in practice the read is the bottleneck. The usual culprits are a cloud placeholder being downloaded, a network share, a drive slower than its label, a security agent filtering every read, or Spotlight indexing the same volume.

Is SHA-256 slow?

No. At roughly 2 GB/s on Apple Silicon it outruns nearly every source of data you could point it at. The only place it becomes the limiting factor is a fast internal SSD, where a single digest is about a tie with the drive and the eight the app computes from one read make the computation the slower half.

Will choosing MD5 instead of SHA-256 make hashing faster?

Only if the computation is what you are waiting for, and it almost never is — compare the rate on screen with what that drive or share can physically deliver and you will usually find the storage is the limit, in which case MD5 saves you nothing at all. It also costs you collision resistance, which has been trivially breakable since 2004, so it is a bad trade even when it is a real one.

Why is hashing an external drive so much slower than the internal one?

Because an Apple internal SSD reads several gigabytes a second and most external setups do not come close. A port negotiating a slower mode, a charge-only cable, a shared hub, a bus-powered enclosure throttling as it warms up, or a hard disk reading from its inner tracks will each cut the rate substantially. Time a plain Finder copy of the same file first: if the copy is no quicker, the drive or the cable is the limit and the hashing was never the problem. Then change one variable at a time.

Does hashing use a lot of CPU?

Less than you would guess, and on a slow source almost none, because the processor spends most of its time waiting for bytes. You will see real CPU use only when the data arrives as fast as the arithmetic can take it — a big file on an internal SSD, particularly with several algorithms requested at once.

Can I make it faster by hashing several files at the same time?

Rarely, and on a hard disk it makes things worse by turning one sequential read into several competing ones. On fast NVMe storage the gain is marginal, because the real cost in a large batch is the per-file work of locating, opening and closing each file rather than anything that parallelizes cleanly.

Does hashing a huge file use a lot of memory?

No. The file is streamed and only the algorithm's small internal state is kept between chunks, so memory stays flat at roughly 16 MB whether the file is 2 MB or 900 GB. If your Mac is under memory pressure during a run, something else is responsible.