Spotlight/QuickLook/DNS/font caches

Spotlight Index Using 30GB+? How to Shrink a Bloated .Spotlight-V100 (2026)

Opening Spotlight index too large on Mac complaints in forums and you will find the same story: a clean 512 GB SSD shows only 380 GB free even though the user's documents folder is modest. The culprit is almost always the hidden .Spotlight-V100 bundle that macOS plants at the root of every indexed volume. On machines that hold large Xcode builds, virtual machine images, or media archives, this index can balloon past 30 GB — and macOS System Settings will helpfully classify it as "System Data," making it invisible in normal storage charts. This guide explains what is actually inside that folder, how to measure it accurately, and how to safely reclaim the space without breaking Spotlight search.

What Lives Inside .Spotlight-V100

Spotlight builds an inverted-word index, a metadata store, and several ancillary journals to power fast system-wide search. The bundle is located at the root of every APFS or HFS+ volume that Spotlight is allowed to index. On a typical startup disk it sits at:

  • /.Spotlight-V100/ — the main database for your boot volume
  • /Volumes/MyDrive/.Spotlight-V100/ — one copy per external or secondary volume

Inside you will find subdirectories such as Store-V2, which holds the core inverted index, and various .store and .map files. Spotlight also keeps a VolumeConfiguration.plist that records excluded paths. The index mirrors metadata for every file Spotlight has ever scanned, so the bigger and more varied your files, the larger the index grows.

Why the Index Gets So Large

Several common scenarios cause runaway index growth:

  • Xcode DerivedData — Located at ~/Library/Developer/Xcode/DerivedData, build products contain thousands of object files, Swift module caches, and symbol maps. Spotlight indexes each one.
  • Node modules — A single JavaScript project can have hundreds of thousands of files nested inside node_modules. Each gets an index entry.
  • Virtual machine disk images — A .vmdk or Parallels .pvm bundle can be a single multi-GB sparse file, but Parallels working directories contain many sub-files that Spotlight indexes individually.
  • Rust and Maven caches~/.cargo/registry and ~/.m2/repository grow silently into the gigabytes and are not excluded by default.
  • Photo libraries and video assets — macOS Photos stores originals under ~/Pictures/Photos Library.photoslibrary/originals. Spotlight reads EXIF and XMP metadata from every image and video.
  • Corrupted or stale incremental journals — After a hard shutdown or kernel panic, Spotlight may fail to compact its journals, leaving behind large orphaned entries.

How to Measure the Index Before You Act

Because .Spotlight-V100 is owned by root and hidden from Finder, you need Terminal to get an accurate reading. Open Terminal and run:

  1. Check the boot-volume index size:
    sudo du -sh /.Spotlight-V100
  2. Check every volume at once:
    sudo du -sh /Volumes/*/.Spotlight-V100 /.Spotlight-V100 2>/dev/null
  3. See a breakdown inside the index bundle:
    sudo du -sh /.Spotlight-V100/Store-V2/*

If the output shows more than 5–10 GB on a standard personal machine, the index has grown beyond normal. Anything above 20 GB almost certainly reflects an unexcluded developer cache or media library that is driving repeated full reindexing.

Understanding Spotlight's Normal vs. Abnormal Sizes

Machine Profile Typical .Spotlight-V100 Size What Drives It
Light user (documents, email, Safari) 500 MB – 2 GB PDFs, mail attachments, browser history metadata
Creative professional (Lightroom, Final Cut) 3 GB – 8 GB RAW images, ProRes proxies, project bundles
Developer (Xcode, Node, Python envs) 8 GB – 25 GB DerivedData, node_modules, .cargo, .m2
Developer + VM images on same volume 20 GB – 50 GB+ All of the above plus VM working directories

How to Shrink the Spotlight Index: Step-by-Step

The most durable fix is to exclude the directories that should never have been indexed in the first place, then force a rebuild. Here is how to do it on macOS Sequoia and Tahoe (2025–2026):

  1. Open System Settings › Siri & Spotlight and scroll to the Spotlight Privacy section (on older macOS it may appear as a separate Privacy tab).
  2. Click the + button and add each directory you want excluded. Good candidates:
    • ~/Library/Developer/Xcode/DerivedData
    • ~/Library/Developer/CoreSimulator/Devices
    • ~/.cargo
    • ~/.m2
    • Any folder that contains exclusively node_modules trees
    • Virtual machine image directories (e.g., ~/Parallels, ~/Virtual Machines)
  3. After adding exclusions, macOS will ask Spotlight to prune those paths from the index automatically over the next hour. To force an immediate full rebuild instead, run:
    sudo mdutil -E /
    This erases and rebuilds the index from scratch. Spotlight search will return fewer results for 30–60 minutes while indexing completes.
  4. To verify indexing status after the rebuild:
    mdutil -s /
  5. Optionally, check that the new index size is smaller after 2–3 hours:
    sudo du -sh /.Spotlight-V100

You can also add exclusions from Terminal if the GUI is tedious for many paths:

sudo defaults write /private/var/db/Spotlight-V100/VolumeConfiguration.plist Exclusions -array-add "/Users/your-user/.cargo"

After editing the plist directly, restart the Spotlight metadata server:
sudo launchctl stop com.apple.metadata.mds && sudo launchctl start com.apple.metadata.mds

Handling External and Network Volumes

If you use Time Machine backup drives, external SSDs, or network-attached storage, each volume gets its own .Spotlight-V100. On a Time Machine disk this index can grow very large because every backup snapshot contains file-system metadata that Spotlight tries to index. The safest approach for Time Machine drives is to add them to the Spotlight Privacy list entirely. For external work drives, add only the subdirectories you do not need to search from Spotlight (such as raw footage archives).

To disable indexing on a specific external volume from Terminal:
sudo mdutil -i off /Volumes/MyExternalDrive

To re-enable it later:
sudo mdutil -i on /Volumes/MyExternalDrive

Keeping the Index Lean Going Forward

The best long-term strategy is to maintain a clear picture of which directories on your Mac are large, ephemeral, and machine-generated — those are exactly the ones that should never be indexed. If you use Xcode regularly, DerivedData can exceed 50 GB on its own; excluding it from Spotlight shrinks both the index and search noise at the same time, since Spotlight results for compiler artifacts are rarely useful. Similarly, node_modules folders inside project directories are usually excluded in .gitignore for good reason — they are transient and can be recreated — and Spotlight search inside them is almost never intentional. For a broader look at what else might be filling your Mac's storage, the same principle applies: machine-generated caches and build artifacts are the first things to audit.

It is also worth doing a periodic cleanup of the caches that feed the index. Applications that write aggressively to ~/Library/Caches or ~/Library/Application Support will keep Spotlight busy re-indexing updated files. A tool like Crumb can audit all of these at once and show what is safe to remove before you delete anything, which is especially useful when you are not sure which cache directories belong to which apps. You can also learn more about what cache files are on a Mac to understand which ones are generally safe to clear.

When a Full Disable Makes Sense

Some developers and power users disable Spotlight indexing entirely on dedicated build volumes that never need to be searched. This is a legitimate choice if you have a secondary APFS volume that holds only build artifacts or VM images. Disabling it frees up the index space immediately:

  1. Disable indexing: sudo mdutil -i off /Volumes/BuildDisk
  2. Remove the existing index: sudo rm -rf /Volumes/BuildDisk/.Spotlight-V100

Do not run the above commands on your boot volume unless you are prepared to lose Spotlight search entirely on that Mac. The boot volume index is required for many system features beyond search, including some Core Data queries and Siri suggestions.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

Is it safe to delete .Spotlight-V100?
It is safe to let macOS rebuild the Spotlight index by running `sudo mdutil -E /`, which erases and recreates .Spotlight-V100 automatically. Manually deleting the folder as root can also work on non-boot volumes, but on your startup disk it is safer to use mdutil so macOS controls the process. Search will be temporarily slower while the index rebuilds, usually 30 to 60 minutes.
Where is the Spotlight index stored on my Mac?
The main Spotlight index for your boot volume lives at /.Spotlight-V100 at the root of your startup disk. Every additional APFS or HFS+ volume — including external drives and Time Machine disks — gets its own .Spotlight-V100 folder at the root of that volume. These folders are hidden from Finder but visible in Terminal.
Will I lose my files if I rebuild the Spotlight index?
No. Rebuilding the Spotlight index only affects search metadata — your actual files are completely untouched. After a rebuild, Spotlight search results will be incomplete for an hour or so while macOS re-indexes your files, then everything returns to normal.
Why does macOS count .Spotlight-V100 as System Data?
macOS categorizes files owned by root or managed by system services as System Data in System Settings › General › Storage. Because .Spotlight-V100 is a root-owned hidden directory maintained by the mds (metadata server) daemon, its size gets rolled into the System Data bucket and is not broken out separately in the GUI.
How often should I rebuild the Spotlight index?
Most users never need to manually rebuild it — macOS manages incremental updates automatically. A manual rebuild is worth doing after a significant change in what you want excluded (for example, adding Xcode DerivedData to the Privacy list), after a hard shutdown that may have corrupted the journals, or any time the index appears to have grown beyond 20 GB on a personal machine without obvious cause.