Clear Mac Caches Without Losing Data

A true cache can be rebuilt, but a folder named Cache is not automatically safe to delete. Apps sometimes mix offline downloads, session state, indexes, and unsynced work beside disposable files. The useful skill is not learning a list of paths; it is identifying the owner, the rebuild source, and the consequence of a cache miss.

Here is what each kind is, where it lives, and how to clear it without collateral damage.

Cache, state, and data are three different things

Everything an app keeps outside its bundle falls into one of three buckets, and only the first is intended to be replaceable:

• Cache is recomputable: rendered thumbnails, compiled output, or downloaded files kept for speed. Deleting it can mean slower launches, network use, and lost offline availability.
• State is your session: open windows, scroll positions, drafts. Losing it is annoying but not catastrophic.
• Data is irreplaceable: your messages, your photos library, your saved logins. Deleting it is a real loss.

The folders below can mix these, which is why "clear all cache" tools are risky. A path under ~/Library/Caches is a useful clue, not a complete safety proof.

Clear a cache for a reason

Cache cleanup is justified when a measured cache is consuming needed space, an app's documented troubleshooting steps call for it, or an index is demonstrably stale or corrupt. It is not useful as a ritual. macOS and many apps already evict cache under pressure, and rebuilding everything can briefly make performance, battery use, and network traffic worse.

Where cache lives on a Mac

• ~/Library/Caches/ holds per-app user caches, the largest everyday group. Each subfolder is named by bundle identifier, like com.google.Chrome.
• /Library/Caches/ holds system-wide caches.
• /System/... is protected by System Integrity Protection and is not yours to touch. Never try.

Preferences deserve a special warning. Files in ~/Library/Preferences are your settings, not cache, and macOS caches them in memory through a daemon called cfprefsd. Deleting a .plist by hand while the app is running can lose settings, be overwritten by the active preference state, or leave the app and its cached state out of sync. Change preferences in the app first. Use defaults only for a documented preference domain and key, not as a generic cleanup command.

The caches worth clearing, and the big ones

Find your largest caches before clearing anything:

du -sh ~/Library/Caches/* 2>/dev/null | sort -h

The heaviest lines are usually:

• Browsers. Safari, Chrome, and others hold gigabytes of cached pages and media. Clear these from the browser's own settings, which is safer than deleting the folder, since it separates cache from your history and logins.
• Developer tools, which dwarf everything else on a coding Mac. Xcode's ~/Library/Developer/Xcode/DerivedData can reach tens of gigabytes, and package managers keep their own stores: brew cleanup clears old Homebrew downloads, npm cache clean --force clears the npm cache, and ~/Library/Caches/ holds caches for Swift Package Manager, pip, and others. npm's cache is self-healing, so start with npm cache verify; reserve npm cache clean --force for an intentional space-recovery or troubleshooting pass.
• QuickLook thumbnails, rebuilt on demand: qlmanage -r cache.

Always quit the owning app first. Cache files are often open or memory-mapped while the app runs, and deleting them mid-write can corrupt the cache database the app depends on, which turns a space cleanup into a broken app.

Browser cache deserves another distinction: cookies, site data, history, saved passwords, and cached page resources are separate controls. Select only cached content when the goal is disk recovery. Clearing all browsing data can sign you out or remove offline site state without reclaiming materially more cache.

The safer way, by category with review

Doing this by hand works, but bundle identifiers and folder names are not always readable. A cleaner should show the owner, path, size, and category before touching anything, and it should exclude profiles, documents, model stores, and conversation history by design. Mole's Clean view follows that review-first model. The broader lesson is that a skip-list and path validation matter more than an impressive count of items found.

Under the hood: what "safe to clear" actually checks

You can skip this, but it shows why "clear it by category with review" is more than a slogan. Here is what the checks look like in practice, from the cache logic in Mole's open-source command-line tool (lib/clean). The native app mirrors many of these rules in Swift instead of invoking the CLI.

The details are the point. A safe implementation uses the package manager's own cleanup interface when possible, refuses to touch a build cache while its daemon is active, validates every resolved path, times out slow size probes, and preserves explicitly protected folders. If the owning tool is missing or the category is ambiguous, review is safer than guessing. A recursive deletion of an entire Caches folder bypasses every one of those checks.

What not to clear, even in the name of cache

• AI assistant chat history and transcripts. These sit near caches but are irreplaceable data. Never delete them for space.
• Preferences and saved logins, as opposed to disposable cache.
• Anything under /System.
• Any folder whose purpose you cannot identify.

The rule is the one that keeps every Mac cleanup safe: if you cannot tell what a file is for, do not delete it.

A safe cache-cleaning sequence

Measure first, quit the owner, use its built-in storage or cleanup command, remove one category at a time, and reopen the app before emptying Trash. Never treat preferences, profiles, chats, documents, or unknown Application Support data as cache. Clear only when the space or troubleshooting benefit exceeds the rebuild and download cost. That method is slower than "delete all," but it remains safe when app internals change.