Spotlight · macOS process

mdworker on Mac: why there are so many, why they use CPU, and what to do

mdworker is a Spotlight helper that reads your files so search can find them. Spotlight runs many copies at once, so seeing five or ten mdworker or mdworker_shared rows in Activity Monitor is normal. They are busy after a macOS update, a big download, or a new external drive, and usually settle in 10 to 30 minutes, sometimes a few hours after an update. You do not need to quit them. If they are still busy a day later, one corrupt file or a huge code folder is the usual cause, and excluding that folder in Spotlight settings fixes it.

Let it finishIt is doing a job and stops on its own. Quitting it only makes it start over.

Updated 7 November 2026 · macOS 12 Monterey to macOS 26 Tahoe · 5 min read

What it is
A Spotlight indexing worker. The parent, mds, hands it files to read; mds_stores writes the results into the index.
Normal
Several rows at once, each at 10 to 60 percent CPU for a while after an update or a large copy, then near zero.
Not normal
High CPU for more than a day with no new files, or one mdworker stuck on the same file for hours.
Safe to quit?
Yes, but pointless. Spotlight relaunches it within seconds and starts the file again.
The one safe fix
Let it finish. If it never does, add the problem folder to Spotlight's exclusion list in System Settings.

What mdworker does

Spotlight is three processes working together. mds is the manager: it watches for new and changed files and decides what needs indexing. mdworker is the worker: mds hands it a batch of files, and each worker opens them, pulls out the text, titles, dates and other metadata, and sends the results back. mds_stores then writes everything into the index on disk. The _shared variant does the same work for files that need Apple's own importers, and the whole group runs under the _spotlight user, which is why you cannot see what it is doing from your account.

That is why you never see a single mdworker. Spotlight spins up a pool of them so it can read many files in parallel, and each one is sandboxed, so if one chokes on a broken PDF the rest keep going. Eclectic Light, the most careful source on this, lists mds, mdworker and mdworker_shared among the regular offenders that are completely normal to see high for a while.

Everything that uses the index benefits: Spotlight search, the Finder search box, Mail search, Photos search, and Siri Suggestions. When indexing is behind, those searches miss recent files. That is the trade: a busy hour now for instant search later.

What normal looks like

The right question is not how high the CPU is but how long it has been high and what changed on the disk. These are the patterns people actually see:

Quiet Mac, index up to date0 to 3 percentA worker wakes for a second when you save a file, then sleeps.
After a big download or copy20 to 60 percentSeveral workers for 10 to 30 minutes, longer for photo or video folders.
After a macOS update50 to 100 percent, several rowsThe index is often rebuilt. A few hours is normal; overnight on a slow drive.
Stuck on one file for a dayOne worker pinned at 90 percent plusNot indexing, looping. Usually a corrupt document or a huge node_modules folder.
Typical mdworker CPU, totaled across all workers, by what just happened to your files. Times from the Safe to Quit knowledge base and Apple Community reports.

Memory is rarely the problem. Each worker holds a few dozen megabytes. What people notice is the fan, the Mac feeling slow, and the drive light flickering for a long time. On a Mac with a spinning external drive attached, the sound of the drive is often the first clue that Spotlight has started indexing it.

Why mdworker is using CPU right now

Almost every case comes down to one of these:

  1. Something big just changed. A macOS update, a Time Machine restore, a migration from an old Mac, or a large copy from a camera card. Spotlight has thousands of new files to read. This is the normal case and it ends on its own.
  2. A new drive was plugged in. External disks and USB sticks are indexed the first time they appear. A full 2 TB photo drive can keep workers busy for hours.
  3. A developer folder. A single node_modules or build folder can hold hundreds of thousands of tiny files. Spotlight tries to read every one. Excluding the folder is the fix, not waiting.
  4. One corrupt file. A worker opens a damaged PDF, email database or old app document, fails, gets relaunched, and tries the same file again. An Apple Community regular put it plainly: corrupt documents from obsolete applications are the usual culprit.
  5. Cloud sync feeding it. Dropbox, Google Drive or iCloud Drive downloading a large folder creates thousands of file changes, and Spotlight follows behind. It settles when the sync does, so check fileproviderd or bird too.
  6. A damaged index. Rare. Searches return nothing or wrong results while workers run forever. Re-indexing fixes it, and you can do that from System Settings without any terminal command.

Is it safe to quit mdworker?

Quitting an mdworker does no harm. It is designed to be thrown away: mds notices, launches a fresh worker, and the index carries on. That is also why quitting does not help. Within seconds the new worker picks up the same batch, and if the problem is a corrupt file it hits the same wall. Force quitting mds or mds_stores is the same story with more risk, because an interrupted index write can leave the index in a state that needs a full rebuild.

The honest answer is that quitting is safe, useless and slightly counterproductive. If you want it to stop using CPU, the only things that work are letting it finish or taking the problem folder away from it.

What are you about to quit?

Use the checker above for any process you are unsure about. For Spotlight workers it will tell you the same thing: wait, or exclude.

What to do, in order

  1. Check what just changed

    Did you update macOS, plug in a drive, download a big folder or copy photos in the last day? If yes, this is normal indexing. Plug in the charger, leave the lid open, and give it until tomorrow morning before doing anything else.

  2. Watch the trend, not the number

    Open Activity Monitor, click the CPU column to sort, and check again in 20 minutes. Normal indexing has workers come and go, with the total slowly falling. A problem looks like one worker pinned high the whole time.

  3. Find the file it is stuck on

    In Activity Monitor, select the busy mdworker, click the i button, and open the Open Files and Ports tab. The file at the bottom of the list is usually the one it is chewing on. If it is a huge code folder or an old document, you have your answer.

  4. Exclude the folder

    Open System Settings, go to Siri & Spotlight, scroll down to Spotlight Privacy, and add the folder with the plus button. Spotlight stops indexing it immediately and the worker moves on. Good candidates: node_modules, virtual machine images, a folder of old app documents.

  5. Move or archive the corrupt file

    If the stuck file is a single document you still need, move it into a folder you have excluded, or zip it. If you do not need it, put it in the Trash. Do not touch anything inside the hidden Library or System folders.

  6. Rebuild the index from settings

    If search itself is broken and workers never settle, add your whole startup disk to Spotlight Privacy, wait a minute, then remove it again. Spotlight erases the index and starts fresh. Expect an hour or more of busy workers, then calm.

  7. Restart if nothing changed

    A restart clears stuck workers and any held-open files. It will not stop real indexing, but it does break a loop. If the same worker is back at full CPU the next day with no new files, the index rebuild above is the next step.

When to worry

Spotlight is not a security risk and mdworker is not malware, so the worry is only about time and battery. Here is the line between normal and stuck, as a timeline:

  1. 0 to 30 minAfter a copy or download: several workers busy. Normal. Do nothing.
  2. Up to a few hoursAfter a macOS update or a new drive: workers busy, drive active. Still normal. Leave it on power.
  3. Next morningShould be quiet. If workers are still high with nothing new on disk, check the open files.
  4. Day 2 and beyondSame worker, same file, same CPU. Exclude the folder or rebuild the index. Waiting longer will not help.
How long Spotlight indexing is allowed to take before it counts as stuck.

The thing that separates a real problem from a long index is whether the work is ending. That is hard to judge from a single Activity Monitor glance, which is where Safe to Quit helps: it watches every process over hours and flags the ones that stay high instead of falling, so you know whether to wait or to go looking for the folder.

If you came here because the whole Mac feels slow and not just Spotlight, start with why is my Mac so slow, and if the fan is the real complaint, Mac overheating and fan loud covers what is usually behind it.

Look up another process

Spotlight is usually just one of several busy names. Type any process from Activity Monitor to get the plain-English version of what it is and whether to leave it alone.

Answers come from the same knowledge base the app uses: 369 parts of macOS, each with a plain-English line and a verdict.

What people hit, in their words

“In the Activity Monitor it's always "mdworker" running between 50-65 percent CPU usage.”

“Could cloud services like Adobe CC, Dropbox, etc. being causing this?”

“Corrupt documents particularly ones associated with obsolete applications are probably to blame.”

A two-minute walkthrough of the Spotlight exclusion fix

mds_stores or mdworker high CPU : Fix by The Geek Page. Shows the System Settings route. Skip any step that involves Terminal commands; the exclusion list is enough.

Questions people ask

What is mdworker on my Mac?

mdworker is a worker process for Spotlight, the search built into macOS. Its parent process, mds, hands it files to read; it extracts text and metadata and passes the results to mds_stores, which writes the index. Spotlight runs several workers at once, so seeing many mdworker and mdworker_shared rows in Activity Monitor is expected, not a sign of a problem.

Why are there so many mdworker processes?

Because Spotlight indexes files in parallel. Each worker is sandboxed and handles a batch of files, so one bad file cannot take the whole indexer down. On a Mac with several cores you will often see five to ten workers during a big index, and they disappear on their own as the backlog clears. The count is not something you need to reduce.

How long does mdworker take to finish?

Usually 10 to 30 minutes after a large download or copy, and up to a few hours after a macOS update, when the index is often rebuilt from scratch. A new external drive full of photos can take longer. If the workers are still busy the next day with nothing new on the disk, it is stuck on a folder or a file, and excluding that folder in Spotlight Privacy is the fix.

Can I quit mdworker on Mac?

You can, and nothing breaks, but it relaunches within seconds and resumes the same work. If it was looping on a corrupt file it will loop again. Quitting mds or mds_stores is riskier because an interrupted index write can force a full rebuild. The useful moves are to wait, exclude the problem folder, or rebuild the index from System Settings.

How do I stop Spotlight indexing a folder?

Open System Settings, choose Siri & Spotlight, scroll to Spotlight Privacy, and add the folder. Spotlight stops reading it immediately and any worker stuck there moves on. This is the right answer for code folders like node_modules, virtual machine disks, and folders of old documents from apps you no longer have. You can remove the folder from the list later.

Is mdworker a virus?

No. mdworker is part of macOS and lives inside the protected system volume, which cannot be modified by malware. Its name, location and the _spotlight user it runs as are all standard. If you want a second check, select it in Activity Monitor and look at the path in the info panel: it should start with /System/Library/Frameworks/CoreServices.framework.

Sources and further reading