Where Chrome extension files live on a Mac

People go looking for Chrome extension files on disk for a small number of reasons, and the reason changes what is worth doing once the folder is open. Something disappeared and needs to be recovered. Something looks suspicious and needs to be inspected. A machine is being replaced and the setup should survive the move. Or an old extension stopped working after Manifest V2 was disabled, and the question is whether a copy on disk is any use at all. The path is the same in every case. The answer to the underlying question is not.

The path, and how to confirm it for the right profile

On macOS, Chrome keeps everything under the Application Support folder. The Chromium project documents the default location.

The default location is in the Application Support folder: [Chrome] ~/Library/Application Support/Google/Chrome Source: chromium.googlesource.com

That is the user data directory. Extensions do not live directly inside it. They live inside a profile, and the profile is a subdirectory, so the full shape is this:

~/Library/Application Support/Google/Chrome/Default/Extensions/<extension id>/<version>_0/

The folder named Default is the first profile. Additional profiles are named Profile 1, Profile 2, and so on, in creation order rather than by the name shown in the browser. That naming is the single biggest cause of opening the wrong folder, because a profile labelled Work in the browser might be Profile 3 on disk.

There is a reliable way to skip the guessing. Open chrome://version in the window whose extensions are in question and read the Profile Path field. The same Chromium document describes exactly this method, and the path it prints is the profile directory, with the user data directory being its parent.

Getting there in Finder needs one extra step, since the Library folder is hidden by default. In Finder, use Go, then Go to Folder, and paste the path. The keyboard shortcut for that dialog is Shift and Command and G.

What is actually inside an extension folder

Each installed extension gets a directory named after its ID, and inside that, one directory per installed version. The version directories carry a suffix, so a version 2.0.17 folder appears as 2.0.17_0.

Extension IDs are 32 characters long and use only the letters a through p. They look random because they are derived rather than chosen, which is why the folder listing is unreadable at a glance.

Matching an ID to a name takes ten seconds. Open chrome://extensions, turn on Developer mode, and each card shows its ID underneath the description. Copy the ID, and the matching folder is the one to open.

Inside a version folder, the contents are the extension itself: manifest.json, the scripts and pages it uses, an icons folder, a _locales folder if it is translated, and a _metadata folder holding verification data. The manifest is the file worth opening first. It states the name, the version, and the manifest_version, which is the number that says whether the extension belongs to the current generation or the retired one.

Reading a manifest without being a developer

Four entries in manifest.json answer most of the questions that send people to the folder in the first place.

The permissions list names the browser capabilities the extension asked for, such as reading tabs or storage. The host_permissions list names the sites it may act on, and a single entry of all urls means every page. The content_scripts section shows which pages get code injected into them and what that code is. The background entry, in the current generation, points at a service worker, which is the file that runs when no tab of its own is open.

None of that requires understanding the code. An extension that was installed to convert a file format, yet asks to act on all urls and injects a script into every page, is worth a second look regardless of how the code is written. The manifest is a statement of intent, and it is short enough to read in a minute.

Extensions that arrive from outside the browser

Not everything in the Extensions folder was installed by hand from the Web Store. Chrome supports installation by other software on the machine, and Google's own help notes that installing a Windows or Mac application can install a Chrome extension alongside it. Chrome shows a prompt the next time it opens, with the choice to enable or remove.

Two directories relate to this and sit at the user data directory level rather than inside a profile. External Extensions records extensions registered by other installers. NativeMessagingHosts records desktop applications that are allowed to exchange messages with an extension, which is how a password manager or a note taking app talks to its browser half.

Those folders are worth a look when something reappears after being removed, or when an extension exists that nobody remembers installing. The entry that keeps putting it back is usually the installer, not the browser.

The settings are stored somewhere else

This is the part that turns a folder copy into a disappointment. The Extensions directory holds program code. It does not hold what the extension knows about you.

Look in the same profile directory and several siblings appear:

• Local Extension Settings, which holds the stored data for extensions that keep local state
• Extension State, Extension Rules, and Extension Scripts, used by the browser for runtime data
• Extension Cookies, separate from ordinary browsing cookies
• Secure Preferences, which records which extensions are installed and enabled, protected against tampering

The size of these files is often the surprise. An extension whose code is a few hundred kilobytes can hold far more in stored data after a year of use, particularly anything that caches pages, keeps a clipboard history, or stores rules. Looking at the Extensions folder alone gives a misleading picture of what an extension occupies on the disk.

Two practical conclusions follow. Copying only the Extensions folder to a new Mac carries the code and leaves every configured option, saved login, and rule behind. And an extension deleted from the browser has not necessarily left its stored data behind in the same instant, which matters when the goal is removing something rather than preserving it.

Unpacked extensions are not in there at all

Anything loaded through Developer mode with Load unpacked stays where it was put. Chrome references the original folder rather than importing a copy into the profile, which has two consequences worth knowing.

Moving or deleting that folder disables the extension, and the error will point at a path rather than at a name. Tidying a Downloads folder is a common way to break an unpacked extension without realising it.

The other consequence is a security one. An unpacked extension can be edited on disk while it is installed, and the browser does not verify it against a published copy. That is fine for something being developed on purpose. It is a good reason to be careful about instructions that ask for an extension to be downloaded as a zip file and loaded this way.

Copying the folder is not a backup

The instinct to archive the Extensions folder is understandable, and the result is rarely usable. The folder contents are only half the picture, as above, and reinstalling from the Web Store produces a clean copy anyway for anything still published.

For one whole generation of extensions, the copy is not a route back at all.

All remaining Manifest V2 extensions are removed from the Chrome Web Store. Manifest V2 extensions installed on Chrome 138 or earlier will remain installed, but will be unable to receive any updates and cannot be reinstalled from the Chrome Web Store once removed from Chrome. Source: developer.chrome.com

Manifest V2 extensions were disabled for all users with Chrome 138, in July 2025, and the store removal completed on 31 August 2026. If an extension folder on disk contains a manifest.json with manifest_version set to 2, that folder is an archive of something that will not run in a current Chrome and cannot be restored from the store. The useful next step is finding a maintained replacement, not preserving the files.

There is one more reason the copy rarely helps. Chrome verifies what it installs, and the ID is tied to the package rather than chosen by whoever holds the files, which is why a folder dropped into place by hand does not simply become an installed extension on the new machine. The supported routes back are the store, sync for a signed in profile, and loading an unpacked copy in Developer mode with the caveats above.

The reasonable backup is therefore a list rather than a folder: the names and IDs of what is installed, kept somewhere outside the browser. Rebuilding from that list takes a few minutes on a new machine and produces a working setup.

Every profile keeps its own copy

Anyone using more than one Chrome profile has more than one Extensions directory, and the same extension installed in three profiles exists three times on disk, each with its own stored data. That is by design, since profiles are meant to keep things apart.

With profiles, you can keep all your Chrome info separate, like bookmarks, history, passwords, and other settings. Source: support.google.com

The same help page is direct about the limit of that separation: anyone with the device can switch to any other profile on it. Separation of data between profiles is not a lock on the device.

For the file question at hand, the practical effect is that inspection and cleanup have to be repeated per profile. An extension removed from the profile in front of you is still installed, still updating, and still holding data in the other four. This is also why a Mac with many profiles has a much larger Chrome directory than expected, and why one badly behaved extension can appear to come back after being deleted.

If the reason for keeping several profiles is to hold work applications apart rather than to separate people, it is worth asking whether the browser is the right place for that split at all. A browser that keeps each web app in its own window with its own session reaches the same separation without multiplying installed extensions across profiles, and the Workspaces page describes how those groups are laid out.

What to do with what you found

Open chrome://version, read Profile Path, and go there in Finder rather than guessing which numbered profile is which. Open the manifest.json of anything unfamiliar and check the name and the manifest_version before deciding what it is. Then write down the IDs of the extensions worth keeping, because that list, not the folder, is what will rebuild the setup on the next machine. If the folder count is high because the same tools are installed in profile after profile, the fix is at the level of how the workspace is arranged, and SpaceDeck is built around giving each application its own place on macOS.