The hidden Library folder on a Mac and what lives in it

The Library folder is where macOS and your applications keep everything that is not a document. There are three of them. The one people mean sits inside your home folder, hidden by default. Most of what is inside is app data that will not regenerate if you remove it.

Almost every troubleshooting thread eventually says go to your Library folder. Almost none of them says what you will find when you get there.

There are three Library folders, not one

This is the first thing that trips people up. An instruction that says open Library is ambiguous until you know which one it means.

The tilde is shorthand for your home directory. On a Mac with one account the third path expands to /Users/yourname/Library.

Everything below is about that third one. It sits on the data volume rather than the system volume, which is the reason Disk Utility lists a system volume and a data volume separately.

How to open the hidden one

Apple gives you two routes and Finder gives you a third.

Hold Option. Click the desktop so Finder is frontmost, hold the Option key, then choose Go in the menu bar. Library appears in the list while the key is down. Release it and the entry vanishes again.

Make it permanent. Choose Go then Home, then View and Show View Options. Tick Show Library Folder. It stays visible after a restart until you untick it.

Type the path. Press Shift and Command and G together, enter ~/Library and press Return.

Apple hides it deliberately. Nothing in here is a document you created. Apple's own guidance is to keep your own files in Documents rather than anywhere in Library. The folder is hidden because a wrong deletion in here breaks an application rather than losing a file you can re download.

What is actually in there

A full ~/Library holds thirty to sixty items depending on what you have installed. Six of them account for almost everything anyone is ever sent to look at.

Application Support

This is where a traditional application keeps the things it needs to work rather than the things you asked it to save.

Folder names here follow no rule. Some use the application name, some the developer name, some the bundle identifier in reverse domain form. That inconsistency is why a folder you do not recognise is not evidence of junk.

The contents matter more than the name. Message databases, plug ins, downloaded components, scanned templates and in some cases the licence file that proves you paid for the application. Delete a folder in here and an application starts as though it were new, having forgotten every setting and in some cases its registration.

Containers

Every application from the Mac App Store runs sandboxed. Many direct downloads do too. A sandboxed application cannot write wherever it likes. macOS hands it one private folder and confines almost everything it writes to that.

Those folders live in ~/Library/Containers, one per application, named by the bundle identifier. Microsoft Word gets com.microsoft.Word. Apple Notes gets com.apple.Notes.

Open one and you will find a Data folder that mirrors the shape of your home folder. Data slash Documents, Data slash Downloads, Data slash Library slash Caches, Data slash Library slash Preferences. The application sees that as its whole world.

Two consequences follow. A sandboxed application has its own Caches and its own Preferences inside its container rather than in the shared folders, so the same application can appear in several places. And a container holds real user content, not just scaffolding. Notes keeps its database in there.

Group Containers

Sandboxing creates a problem for application families. Word cannot read Excel's container, yet both need the same account details and the same recent file list.

An app group is the answer. Applications signed by the same development team can share one folder in ~/Library/Group Containers, named with the team identifier followed by a name the team chose. Microsoft Office uses UBF8T346G9.Office, which looks like nonsense until you know that the first part is Microsoft's team identifier.

This matters more than it sounds. On a Mac with the current Outlook, the mail store is in a group container rather than in Application Support, which is why guides written before sandboxing send people to a folder that no longer holds anything.

Preferences

The smallest folder in Library by size and the one blamed for most things.

Each file is a property list, named for the application's bundle identifier and ending in .plist. Safari's is com.apple.Safari.plist.

A preferences file holds settings. Window positions, toolbar choices, the last folder you opened, whether you ticked a box three years ago. It rarely holds anything you would call data.

That is why deleting one is a genuine repair step for an application behaving strangely. It is also why it is a poor way to reclaim space. The whole folder on a busy Mac amounts to a few megabytes.

One caution. macOS caches preference values in memory while an application runs, so deleting a plist under a running application achieves nothing. The application writes it back on quit.

Caches

Caches hold work an application has already done so it does not have to do it twice. Rendered thumbnails, downloaded fonts, decoded images, index fragments.

The folder is disposable in principle. In practice the word Caches appears in three separate places on every Mac. Some of what sits under that name is not disposable at all. What is safe differs per application rather than per folder. That calls for a ruling per cache type rather than a rule, which lives in which Mac caches are safe to clear.

Mail

On most Macs that have been in use for a few years this is the largest single folder in Library. It is where the Apple Mail message store lives.

What is inside it has a structure of its own, with a version folder, account folders and a naming scheme that matches nothing you see in Mail itself. That tour belongs to the folder walkthrough for Apple Mail. Reading that store directly is also how an MBOX converter for Mac gets mail out without asking Mail to export anything.

One more thing about size. This folder grows with use rather than with installs, so a Mac three years old has a Library many times the size of the same Mac on its first day, with no new applications added. Nothing in here is designed to shrink on its own.

What people expect to find and do not

Half the confusion around this folder is about things that are not in it.

Your applications are not here. They sit in Applications. The folder in Library carrying a similar name holds their working data rather than the programs themselves.

iCloud Drive is not here in any form you can browse usefully. It has its own location and its own rules about what is downloaded at any moment.

Photos and Music libraries are not here either. Both default to your home folder, which is why a Library folder measured in gigabytes still does not account for the biggest thing on most Macs.

And the system Library carries none of your data at all. It is macOS itself. Someone sent to Library who lands there will find nothing relevant and every temptation to delete something they should not.

What is safe to touch and what is not

The honest version of this list is shorter than the ones you will find elsewhere.

Read more: Why Apple Mail takes up so much disk space.

Two habits make the difference. Move a folder to the desktop and use the Mac for a week before deleting it, because that is reversible and a delete is not. And treat anything you cannot name as something you have not identified yet.

Why the folder is arranged this way

Read the six folders in order and a pattern appears.

Application Support is the old arrangement, where an application owned a folder and put whatever it wanted in it. Containers and Group Containers are the new one, where macOS owns the folder and lends it to an application under conditions. Preferences and Caches sit across both, existing once in the shared Library and again inside every container.

That overlap is the whole reason this folder confuses people. The same four names appear at several depths. Which copy matters depends on whether the application asking is sandboxed. A guide that gives you one path without saying which generation of application it applies to is going to send somebody to an empty folder.