The ~/Library/Containers Folder on Mac, Explained

Open ~/Library/Containers and you'll find dozens of folders — one for every sandboxed app on your Mac, each holding that app's private data. A few of them can balloon to serious size. Here's what containers are, how to see which apps own the big ones, and what's actually safe to remove.

What a container actually is

macOS runs App Store apps — and many others — in a sandbox. Instead of writing files wherever it likes, each sandboxed app gets one private folder under ~/Library/Containers, named by its bundle ID: com.apple.TextEdit, for example. Inside, macOS builds a miniature copy of your home folder structure (Data/Documents, Data/Library, and so on), and the app treats that as its entire world. Everything it saves, caches, or downloads lands there.

In Finder on macOS 13 Ventura, 14 Sonoma, and 15 Sequoia, most containers display a friendly app name instead of the raw bundle ID. In Terminal you'll see the real folder names, which is often more useful for telling two apps from the same vendor apart.

There's a sibling folder, ~/Library/Group Containers, that holds data shared between apps from the same developer. The same rules below apply to it.

Why do containers get big? Because the sandbox forces everything through them: a mail client's message database, a note app's attachments, a chat app's media history, offline copies kept by sync tools. An app you use daily for years accumulates all of that in one place — which is exactly why the folder is worth measuring, and exactly why it's dangerous to clean carelessly.

See which containers are biggest

1. In Finder, press Shift-Command-G, type ~/Library/Containers, and press Return.
2. Switch to list view with View → as List.
3. Choose View → Show View Options and tick Calculate all sizes — folder sizes are blank in list view until you do.
4. Click the Size column header to sort largest first.

Terminal gets you the same ranking in one line, with real bundle IDs:

# the 20 largest containers, sorted by size
du -sh ~/Library/Containers/* | sort -rh | head -20

What's safe to delete — and what isn't

The only containers you should remove are those belonging to apps you've already uninstalled. A container for an installed app is live data: its settings, its local database, sometimes the documents you created in it. Delete one and, at best, the app resets to factory state on next launch; at worst, you lose real work.

Two rules keep this safe:

• Leave every com.apple.* container alone. Those belong to Apple's own apps, and several store data you'd genuinely miss.
• Delete through Finder, not rm. Dragging a container to the Trash means you can right-click it there and choose Put Back if something breaks — that's your undo until you empty the Trash.

One more reason to stay in Finder: container folders contain symlinks pointing back to real locations in your home folder. Finder's Trash handles them correctly; aggressive third-party "cleaner" apps and hand-typed Terminal commands have historically been where container cleanups go wrong.

If a container's app is long gone and the folder shows real gigabytes in the size column, trash it, wait a few days, then empty the Trash and take the space back. If you're unsure whether an app is still installed, search its name in Spotlight or check /Applications before touching its container.

Finish the job on uninstalled apps

Containers are only one of five places apps leave data behind. For the full sweep — Application Support, Caches, Preferences, and LaunchAgents — see removing leftover files after uninstalling Mac apps.