Library Containers: where sandboxed apps keep everything
Containers holds the private folder of every sandboxed app, and one or two of them are usually huge. How to read the folder and what is safe inside it.
~/Library/Containers is the folder most likely to be misread, because the names inside it are bundle identifiers rather than app names, and because it looks like a cache while containing things that are not.
What a container actually is
A sandboxed app cannot write wherever it likes. macOS gives it a private folder that looks, from inside the app, like a whole home directory: its own Documents, its own Library, its own Caches. That folder is its container, named after the app's bundle identifier.
So a container can hold pure cache, or it can hold the only copy of your data, and the folder name tells you nothing about which. That is the important sentence on this page.
du -sh ~/Library/Containers/* 2>/dev/null | sort -h | tail -15Turning an identifier into an app name
When you cannot place a name like com.tinyspeck.slackmacgap, ask macOS:
mdfind "kMDItemCFBundleIdentifier == 'com.tinyspeck.slackmacgap'"If that prints a path in Applications, the app is installed and the container belongs to something you have. If it prints nothing, you are looking at a leftover from an app that is gone, which is a different problem with a different answer.
Reading the inside of a container
Inside Data/Library | What it is | Safe to clear |
|---|---|---|
Caches | Ordinary cache | Yes |
Application Support | The app's real data | No, look first |
Saved Application State | Window and document state | Yes, you lose reopened windows |
Logs | Diagnostics | Yes |
Preferences | Settings | No, you lose configuration |
The pattern to follow is to clear Caches inside a large container rather than the container itself. That gets most of the space in the cases where the space is cache, and it does nothing dangerous in the cases where it is not.
Group Containers, which is the same idea shared
~/Library/Group Containers holds data shared between apps from the same developer, which is how a suite of office apps or a browser and its extension share state. It is usually much smaller, and the same rule applies: caches inside it are safe, the rest is data.
System processes in the list
Not everything in Containers belongs to an app you launched. Photo analysis, Maps data and Siri suggestions all keep containers, and they rebuild whatever you remove at the cost of redoing work. If a system container is large, it usually means the process is midway through something, and the answer is to leave it and check again in a week.
For the rest of the picture, what is in your Library folder covers Caches and Application Support, which are the two neighbours of this folder and usually larger.
Common questions
What is the Containers folder in Library on a Mac?
It is where sandboxed apps keep their private data, one folder per app named after its bundle identifier. Each container looks like a small home folder from inside the app, with its own Documents, Library and Caches.
Is it safe to delete folders in ~/Library/Containers?
Not as a rule. A container can hold nothing but cache or it can hold the app's only copy of your data, and the folder name does not tell you which. Clearing the Caches folder inside a large container is the safe version of the same idea.
How do I find out which app a container belongs to?
Use mdfind with the bundle identifier, for example mdfind "kMDItemCFBundleIdentifier == 'com.example.app'". If it returns a path in Applications the app is installed. If it returns nothing, the container is a leftover from an app that has been removed.
What is the difference between Containers and Group Containers?
A container is private to one app. A group container is shared between apps from the same developer so they can see the same data, which is how an office suite or a browser and its helper share state. Group containers are usually much smaller.