Terminal vs GUI: The Best Way to Clear macOS System Caches in 2026 (Commands Compared)

macOS accumulates several distinct system caches, and clearing the wrong one the wrong way can break Spotlight search, slow down font rendering for hours, or leave your DNS resolver in a broken state until the next reboot. This guide walks through the four most consequential system caches, shows the exact Terminal commands for each, and compares that approach to using a GUI cleaner. By the end you will know which method is faster, safer, and more appropriate for your situation.

The Four System Caches Worth Targeting

Not every file in ~/Library/Caches or /Library/Caches is equally safe to delete. The caches below are the ones that measurably reclaim space and have well-documented, supported reset procedures:

• Spotlight index: managed by mdutil, stored in hidden .Spotlight-V100 bundles at the root of each volume.
• QuickLook thumbnails: managed by qlmanage, cached in ~/Library/Caches/com.apple.QuickLook.thumbnailcache and a system-level equivalent under /var/folders.
• DNS resolver cache: managed by dscacheutil plus the mDNSResponder daemon, entirely in memory (no folder to delete).
• Font and ATS cache: managed by atsutil, stored under /private/var/folders in per-user and system daemon entries. This one is the riskiest to clear manually.

Clearing Each Cache in Terminal: Exact Commands

Spotlight: mdutil

Rebuilding the Spotlight index is the most common reason people reach for Terminal. The index can grow stale after a major OS upgrade or after moving large folders between drives.

# Disable and re-enable indexing on your startup disk (replace / with a volume path for external drives)
sudo mdutil -E /

The -E flag erases the existing index and starts a fresh crawl. Indexing can take 15 to 60 minutes on a full drive; Spotlight searches will return incomplete results until it finishes. You can watch progress with mdutil -s /.

If you want to stop indexing entirely on a volume (useful for external backup drives):

sudo mdutil -i off /Volumes/BackupDrive

QuickLook Thumbnails: qlmanage

QuickLook stores thumbnail previews so Finder can render them instantly. The cache is safe to clear at any time; previews rebuild on demand.

# Reset the QuickLook thumbnail cache
qlmanage -r cache

On macOS Sequoia and Tahoe, this command also clears the per-user cache under /var/folders. You do not need sudo. A second command resets the QuickLook server itself, which resolves cases where previews appear blank or stale:

qlmanage -r

The thumbnail cache rarely exceeds a few hundred megabytes, but on machines that process large photo or video libraries it can reach several gigabytes.

DNS Cache: dscacheutil

DNS flushing is pure memory work. There is no folder to delete. The two-step procedure is required because macOS uses both the Directory Services cache and the mDNSResponder daemon:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

This is completely safe and instantaneous. It does not require a reboot. The resolver rebuilds its cache on the next DNS lookup. Use this when you are testing DNS changes or experiencing stale resolution for a domain you recently updated.

Font and ATS Cache: atsutil

The Apple Type Services cache stores processed font metrics. A corrupted ATS cache can cause garbled text, missing glyphs in apps like Word or Figma, or very slow app launches when the system is scanning for fonts.

# Remove the user-level ATS databases
atsutil databases -remove

A logout and login is required for the change to take effect. The system-level daemon cache requires sudo and a reboot:

sudo atsutil server -shutdown
sudo rm -rf /Library/Caches/com.apple.ATS

This is the riskiest operation on this list. If you have third-party font management software (Font Explorer, Suitcase Fusion), clearing the ATS cache without deactivating those tools first can corrupt font library state. Proceed only if you have a clear symptom to fix.

The Case for Doing It Manually

Terminal is the right tool when you know exactly which cache is causing a problem. A developer chasing a specific Spotlight regression, a network engineer testing DNS propagation, or a designer clearing a stubborn font glitch all benefit from surgical, targeted commands. Terminal also gives you:

• Full control over which volumes and user accounts are affected.
• Scriptability: you can add these commands to a shell script or launchd job.
• No third-party software dependency.

The tradeoff is real. You need to know which command does what, remember the correct flags, and understand the reboot and re-index implications. Running sudo rm -rf ~/Library/Caches without understanding its contents, for example, will delete legitimate app data alongside stale caches and can break signed-in sessions for apps that store tokens there.

Comparing the Terminal Approach to a GUI App

The debate around mac cache cleaner terminal commands vs a GUI app usually comes down to three dimensions: safety, speed, and reversibility.

Safety

A good GUI cleaner runs the same underlying operations (the same qlmanage -r cache, the same atsutil databases -remove) but adds a safety layer before deletion. It can flag files that are currently in use, warn you about caches that require a reboot to rebuild, and show a per-item "is this safe to delete?" check. Terminal gives you no such gate. If you run the wrong command as root, the damage is immediate.

For the DNS flush or QuickLook reset, Terminal is perfectly safe. For the font cache or anything touching /Library system directories, a reviewed approach reduces the risk of breaking something in a way that takes hours to diagnose.

Speed

Four Terminal commands, each requiring you to look up the right flags, takes five to ten minutes if you are doing it from memory. A GUI app that groups all four into a single reviewed operation takes under a minute, including reading the item list. For routine maintenance, the GUI wins on speed. For a targeted one-off fix, Terminal is faster once you know the command.

Reversibility

Neither approach is reversible in the traditional sense: cache files are not backed up before deletion. The difference is that a GUI tool typically lets you review what will be removed before confirming, which is a practical substitute for reversibility. Time Machine does back up ~/Library/Caches by default in macOS Sonoma and Sequoia, so you technically have a recovery path for user-level caches, but restoring from Time Machine to recover a cache file is not a workflow most people would actually use.

What "Manually Clear Cache vs App Mac" Searches Are Really Asking

People searching for a comparison between manually clearing cache vs using an app on Mac are usually not power users who want raw Terminal access. They have read that clearing caches speeds things up, they found conflicting advice about which folders are safe, and they want a clear answer. The honest answer is: for Spotlight, QuickLook, DNS, and font caches, both methods work, but a GUI tool with a reviewable plan is meaningfully safer for anyone who is not already fluent in what each command does.

The folder you should never bulk-delete is ~/Library/Caches in one sweep. Many guides recommend this and it causes real problems. Delete caches selectively, by app bundle ID subfolder, or let a tool that understands the contents make the call.

Practical Recommendation: When to Use Each

• Use Terminal when you have a specific, diagnosed problem (Spotlight stale on an external volume, DNS not updating, one app's QuickLook previews are broken) and you know the exact command.
• Use a GUI cleaner for routine maintenance, when you want to see a full picture of what is accumulating across all four cache types, and when you want a safety review before anything is removed.
• Avoid bulk rm -rf on cache folders without understanding their contents. The space savings rarely justify the risk of breaking app state.

Crumb handles all four of the operations covered here, runs them through a safe-to-delete check for each item, and shows you a reviewable plan before removing anything. It runs entirely on-device and requires no account. If you want the Terminal-level control without the Terminal-level risk, it is worth a look at cleanwithcrumb.com.