What Is /private/var/folders on Mac and Is It Safe to Delete?

If you have ever opened Finder's Go to Folder prompt or peeked at Disk Inventory X, you may have stumbled across /private/var/folders sitting quietly on your Mac — sometimes holding several gigabytes. Searching for "private/var/folders mac" tends to return alarming Reddit threads or commands that can break things. This guide demystifies the directory, explains what each subfolder does, and shows you the genuinely safe ways to reclaim that space without crashing any running app.

What Is /private/var/folders on Mac?

On macOS, every process that runs — whether it is Safari, Xcode, or a background daemon — needs somewhere to stash ephemeral data: partially downloaded files, compiled bytecode, socket locks, draft autosaves. Apple centralises all of this under /private/var/folders.

The path /var/folders is actually a symbolic link; it resolves to /private/var/folders. Both spellings refer to the same place, so you will see both used in documentation and forum posts.

Why the cryptic two-letter and hash-string names?

The directory layout follows a three-level scheme macOS calls NSFileManager temporary directories:

1. Two-letter prefix — encodes which user session owns the subtree (e.g. 5c, c4). The special name zz always holds the machine-wide (daemon) subtrees.
2. Hash string — a unique identifier for the user session, derived from the UID and boot UUID. It changes with each new user account but stays constant across reboots for the same user.
3. Single-letter subfolders — inside each hash directory you will find C, T, X, and sometimes 0.

You can confirm your own temp and cache paths right now:

getconf DARWIN_USER_TEMP_DIR
getconf DARWIN_USER_CACHE_DIR

Both commands print the absolute path to your personal T and C directories inside /private/var/folders.

What the Subfolders Actually Contain

The C folder is typically the largest. On a busy developer machine it is common to see it hold 1–2 GB of sandboxed app caches. The T folder (TemporaryItems) is where the phrase "TemporaryItems mac" comes from in Finder alerts — it is perfectly normal for macOS to use it heavily.

Why Is /private/var/folders Taking Up Space?

Several things cause var/folders to grow over time:

• App caches — Safari, Chrome, Xcode, Adobe apps, and virtually every sandboxed app on the Mac App Store write cache data to C/ rather than ~/Library/Caches, because the sandbox confines them to their assigned container.
• Compiler artefacts — Xcode deposits dylib caches, clang module caches, and Swift build products here. A single project build can add hundreds of megabytes.
• Stale lock files — When an app crashes rather than quitting cleanly, its lock files in T/ are never removed. These are small individually but accumulate over months.
• Audio and font caches — AudioComponentRegistrar and CoreText both maintain caches here that grow as you install plugins and fonts.

Does macOS Clean This Up Automatically?

Yes — but partially, and on its own schedule.

macOS runs a periodic maintenance job that sweeps T/ at logout (for items in X/) and during low-memory pressure events. Since macOS Monterey, the system also accounts for purgeable space in Storage Management: data in /private/var/folders that macOS considers safe to reclaim on demand shows up as "System Data" (or "purgeable") in About This Mac.

However, the automatic sweep does not touch C/ (caches) proactively. Old app caches from apps you deleted years ago can linger indefinitely because the cache container remains on disk even after the app is gone.

Is It Safe to Delete /private/var/folders?

This is the question almost everyone has, and the honest answer is: it depends on which part.

Safe to delete (when apps are not running)

• Cache containers inside C/ for apps that are currently quit. The app will simply rebuild its cache on next launch, which may make that first launch slightly slower.
• Lock files inside T/ that belong to apps that are not currently open. These are usually zero-byte or tiny files.
• Contents of X/ — macOS intended to delete these at next login anyway.

Do NOT delete (these will break things)

• Any file inside a folder whose owning app is currently running. Deleting a running app's cache container can cause it to crash or corrupt its state.
• The entire /private/var/folders directory or the hash-string parent folder. Doing this as root can force macOS to regenerate the entire structure at next boot, potentially breaking Keychain access, sandboxed app data, and inter-process communication sockets.
• Anything inside zz/ — these are system daemon caches. Deleting them can require a reboot or cause background services to malfunction until they are rebuilt.

Note: Clearing caches is permanent. macOS will not warn you before an app rebuilds its cache, but the rebuild process itself is safe. The risk is deleting the wrong item while the app is running.

How to Safely Clear Space in /private/var/folders

Option 1: Let macOS do it

1. Open Apple menu → System Settings → General → Storage.
2. Click Recommendations or Optimize.
3. macOS will mark purgeable data — including portions of /private/var/folders — as reclaimable and free it under storage pressure.

Option 2: Clear the Clang module cache manually (safe, common for developers)

The Clang module cache lives at a path like:

/private/var/folders/<xx>/<hash>/C/org.llvm.clang.<user>/ModuleCache

You can delete it with:

rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang.$(whoami)/ModuleCache"

Xcode will silently recreate it the next time you build. This is one of the safest manual cleanups available.

Option 3: Clear all user caches at once (quit your apps first)

# Quit all apps first. Then:
rm -rf "$(getconf DARWIN_USER_CACHE_DIR)"/*

This removes only the current user's cache containers. Your documents and settings are not touched. Expect a slower first launch for every app as caches rebuild.

Option 4: Use a tool that understands what is purgeable

Manually hunting through cryptic hash-named directories is tedious and error-prone. Crumb identifies purgeable temp and cache space across /private/var/folders as part of its one-click clean, and its "Is this safe to delete?" AI can explain any specific container if you are unsure. It only targets data macOS considers safe to remove, so you are not making judgment calls on individual hash-named folders. You can download Crumb and run a free cleanup to see exactly what it finds before committing to anything.

What About ~/Library/Caches — Is That the Same Thing?

Not exactly. There are two places app caches land:

• ~/Library/Caches — traditional (non-sandboxed) apps write here. It is directly accessible in Finder via Go → Go to Folder → ~/Library/Caches.
• /private/var/folders/…/C/ — sandboxed apps (Mac App Store apps and some notarized apps) write here instead, because the sandbox redirects cache writes.

If you only clean ~/Library/Caches you may miss a significant chunk of cache data sitting in /private/var/folders. A complete cache cleanup needs to cover both locations.

Summary

/private/var/folders is macOS's per-user scratch space — perfectly normal, automatically maintained to a degree, but prone to accumulating gigabytes of stale app caches and orphaned temp files over time. The safest cleanup targets the C/ cache subfolder for apps that are not currently running, leaves the zz/ system subtree alone, and never removes the parent hash directories themselves. A manual Terminal approach works fine; the tricky part is identifying which cryptic container belongs to which app and whether it is currently in use.