Where Chrome extension files live on a Mac

On a Mac, Chrome stores installed extension files at ~/Library/Application Support/Google/Chrome/Default/Extensions/, where Default is the first profile. Each extension has a folder named after its 32 letter extension ID, and inside it a folder named after the installed version. Other profiles use folders such as Profile 1 and Profile 2 in place of Default. The extension's saved settings are not in that folder. They live next to it, in Local Extension Settings and Sync Extension Settings, again one folder per extension ID.

The rest of this guide shows how to confirm the right profile folder, match a folder to an extension, read what is inside, and avoid the common mistakes people make once they find it.

The path, step by step

Google's Chromium documentation describes the user data directory as the folder that holds profile data such as history, bookmarks and cookies. On a Mac its default location is ~/Library/Application Support/Google/Chrome. Each profile is a subfolder inside it, often named Default. Other Chrome channels use their own folders: Chrome Beta, Chrome Dev and Chrome Canary sit next to Chrome under the same Google folder, and plain Chromium uses ~/Library/Application Support/Chromium.

Inside a profile, the Chromium source code names the folder where extensions are installed. The constants file in the extensions code defines the directory inside the profile where extensions are installed as Extensions. Put together, the full path for the first profile is:

~/Library/Application Support/Google/Chrome/Default/Extensions/

Opening it in Finder

The Library folder in the home folder is hidden by default, which is the usual reason people cannot find the path. The quickest route is Finder's Go menu: choose Go to Folder, which Apple lists as Shift + Command + G in its Mac keyboard shortcuts, paste the path, and press Return.

Confirming which profile folder is in use

Profile folder names do not match the names shown in Chrome. A profile called "Work" in the profile menu may be stored as Profile 3. The Chromium documentation gives the reliable method: open chrome://version in the profile in question and look at the Profile Path field. That line is the exact folder for that profile. Its parent folder is the user data directory. Doing this in each profile window takes a few seconds and removes all guessing.

Matching a folder to an extension

Inside Extensions, every folder name is a string of 32 lowercase letters. That is the extension ID. To see which ID belongs to which extension, open chrome://extensions and turn on the Developer mode switch in the top right, as described in Google's Hello World extension tutorial. Each extension card then shows its ID. The same ID appears in the extension's Chrome Web Store address, so a store link is another way to confirm it.

Inside each ID folder is at least one version folder, such as 1.4.2_0. The version folder name changes when the extension updates, so a path copied last month may point to a folder that no longer exists. Always start from the ID folder and open whichever version folder is inside.

What a version folder contains

A version folder is the unpacked extension. The central file is manifest.json, which declares the name, version, permissions and the scripts the extension runs. Google's manifest file format reference lists every key. The fields worth reading without any programming background are:

Field in manifest.json	What it says
name and version	The extension and the installed version
permissions	Browser features it can use, such as tabs or storage
host_permissions	Which websites it can read or change
content_scripts	Scripts injected into pages, and on which sites
background	The service worker that runs behind the scenes

Some names start with a placeholder such as __MSG_appName__. That means the readable name is in the _locales folder, which the Chromium constants file defines as the locale folder inside an extension. Each language has a subfolder with a messages.json file holding the translated strings.

There is also a _metadata folder, which the same source file describes as a directory reserved for metadata generated by the web store or by Chrome. It holds verified_contents.json, which Chrome uses to check that extension files have not been altered.

Checking what an extension can reach

Reading host_permissions in the manifest shows what an extension asked for when it was published. What it is allowed to do right now is set in Chrome itself, and it can be narrowed without touching any file. Google's Chrome Web Store help on managing extensions gives the steps: open the More menu at the top right, choose Extensions, then Manage extensions, and select Details on the extension. Under Permissions, sites can be added next to Allowed sites, or removed from the list. If the option to add sites does not appear, change the setting "Allow this extension to read and change all your data on websites you visit" to On specific sites.

This is a better tool than the folder for most worries about an extension. An extension that only needs to work on a company's ticket system can be limited to that one domain, and it then has no access to webmail, banking or anything else open in the same profile. The manifest still lists the broader request, but Chrome enforces the narrower setting.

The same help page covers removal. Right clicking the extension's icon next to the address bar and choosing Remove from Chrome uninstalls it, as does the Remove button on the Manage extensions page, followed by a confirmation. Either route removes the files from the Extensions folder and, as the storage reference notes, clears the extension's local storage.

Where extension settings and data live

The files in Extensions are the code. What each extension has saved, such as options, lists and login tokens for its own service, is stored elsewhere in the profile. The Chromium constants file names three folders for this:

Folder in the profile	What it holds
Local Extension Settings	Per extension local settings
Sync Extension Settings	Per extension settings that sync with the Google account
Managed Extension Settings	Per extension settings set by an administrator

Each one contains a subfolder per extension ID, stored as a small database rather than readable text. These folders match the storage areas described in Google's storage API reference. According to that page, local storage is cleared when the extension is removed and has a limit of 10 MB unless the extension requests unlimited storage. Sync storage is limited to roughly 100 KB in total and 8 KB per item, and Chrome keeps it locally while offline and resumes syncing once back online.

This explains a common surprise. Reinstalling an extension from the store on the same profile often brings back a blank set of options, because removing it cleared the local area. Signing in on another Mac brings back only what the extension chose to keep in sync storage, which is small by design.

Extensions installed from outside the store

Some extensions arrive without anyone clicking Add to Chrome, usually alongside a desktop app such as a password manager. Google documents how this works in its guide to alternative installation methods. On macOS, an app places a JSON file named after the extension ID in one of two folders:

• For one user: ~/Library/Application Support/Google/Chrome/External Extensions/
• For all users: /Library/Application Support/Google/Chrome/External Extensions/

The JSON file points to an update address, and Google states that on Windows and macOS that address must point to the Chrome Web Store. Since Chrome 44, Chrome on a Mac does not accept external installs from a local CRX file, and users have to confirm the extension in a dialog before it is enabled.

If an extension keeps coming back after being removed, these two folders are the first place to look. A JSON file there means another app on the Mac is asking Chrome to install it. Removing the app, or turning off its browser integration in that app's own settings, is the clean fix. Deleting the JSON file alone may not stick, since the app can write it again.

Unpacked extensions and the mistakes to avoid

An extension loaded with the Load unpacked button in Developer mode does not live in the Extensions folder at all. Chrome runs it straight from the folder that was selected, wherever that is. Moving or deleting that folder breaks the extension. The Chromium source also defines a separate UnpackedExtensions folder in the profile for extensions installed from a zip file.

Three habits cause most of the trouble after someone finds the folder.

First, editing files inside a store extension's version folder. The verified_contents.json check exists to catch altered files, and an update replaces the folder anyway.

Second, treating a copy of the Extensions folder as a backup. The copy contains code that the store can supply again at any time, and none of the saved settings, which live in the settings folders above. A useful backup is the extension's own export option, if it has one, or the Chrome account sync for the extensions list.

Third, deleting folders while Chrome is running. The safe way to remove an extension is the Remove button on chrome://extensions, which also clears its local storage.

When the real issue is too many profiles

People often go looking for extension folders because one Mac has several Chrome profiles, each with its own copy of the same extensions, and something behaves differently in one of them. Every profile has its own Extensions folder and its own settings folders, so the same password manager in four profiles is four installs with four sets of data.

Profiles are often created only to keep two accounts of one web service signed in at once. A browser that gives each web app its own session removes that reason. The app aggregation browser covered on this site is a macOS app that keeps a separate cookie container for each web app, as its features page describes, so two accounts of the same service can stay signed in side by side without a second Chrome profile. Its import tab can read bookmarks from a chosen Chrome profile, without changing anything in Chrome. The pricing page lists a free plan with one workspace and up to three apps, a 14 day trial, and Pro from $5 a month billed yearly or $129 one time, with multiple accounts per service as a Pro feature.

What to change first

Open chrome://version in the profile in question, copy the Profile Path, and open its Extensions folder with Go to Folder. Match folders to extensions with Developer mode on chrome://extensions, and look in the settings folders, not the code folder, for anything an extension saved. If the folder hunt started because of too many profiles for too many accounts, see how SpaceDeck keeps each web app in its own space.