Chrome profile location on a Mac, and how to change it

Two questions arrive together in this search. The first is where Chrome puts profile data on a Mac, which has a short answer. The second is whether that place can be changed, which has a longer one, because Chrome offers no setting for it and the mechanism that does exist behaves differently from what most people expect. It also moves something that is not obvious, and that side effect is usually the reason the move disappoints.

Where the data sits on a Mac

Chromium documents the default for every platform. On macOS it is inside the user library:

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

Two levels are at work in that path, and confusing them is what makes the rest hard. The user data directory is the folder above. Individual profiles are subdirectories inside it, named Default for the first one ever created and Profile 1, Profile 2 and onwards for the rest, in creation order. Preferences, bookmarks, cookies and extensions belong to a profile. Things that apply to the whole installation, including the file that records what each profile is called, belong to the user data directory.

Rather than reading the path from documentation, it can be read from the browser. Chromium describes the method: open chrome://version, look at the Profile Path field, and take the parent of that path as the user data directory. The value shown is the profile currently in front, so the answer differs per window.

Other channels are stored separately. Chrome Beta, Chrome Dev, Chrome Canary, Chrome for Testing and Chromium each get their own directory beside the stable one, which is why running Canary alongside Chrome never disturbs the main setup.

One thing that is not stored where people assume: the display name shown on the profile switcher. That label lives in a small record inside the user data directory, not in the profile folder itself. Renaming a profile in the interface changes the label and leaves the folder name alone, so a profile called Work can permanently occupy a folder called Profile 7. Any command or script that targets a profile has to use the folder name.

The cache is not in that folder

This is the fact that decides whether moving the directory does what somebody hoped. On macOS the cache is not stored with the profile by default. Chromium sets it out as a rule with two branches:

If Library/Application Support is an ancestor of the profile dir, the user cache dir is Library/Caches plus the relative path from Application Support to the profile dir. Otherwise, the user cache dir is the same as the profile dir. Source: chromium.googlesource.com

While everything stays in the default place, the first branch applies. Browsing cache for each profile sits under the Caches folder, mirroring the profile structure, and it is the part that grows fastest and matters least.

Move the user data directory anywhere outside Application Support and the second branch applies instead. The cache stops being separate and lands inside the moved directory. Someone relocating profiles to an external disk in order to reclaim internal space therefore gets a different result than intended: the cache, previously written to the internal disk in a folder that macOS is happy to clear, now gets written continuously to the external one. On a slower or bus powered drive, that is felt on every page load.

Changing it, and the fact that it is per launch

There is no preference for this inside Chrome. The only supported mechanism is a command line flag:

On most platforms, the user data directory can be overridden by passing the --user-data-dir command-line flag to the Chrome binary. Source: chromium.googlesource.com

On a Mac the flag is passed through the open command, using -n to force a new instance and --args to hand the rest to Chrome:

open -na "/Applications/Google Chrome.app" --args --user-data-dir="$HOME/Documents/ChromeAlt"

The consequence people miss is that this is a property of one launch, not of the installation. Clicking the Dock icon, opening Chrome from Spotlight, or following a link from Mail all start Chrome the ordinary way with the ordinary directory. A location change made this way applies only to sessions started through the command.

Chromium documents a way to make it permanent enough for daily use, by wrapping the command in a small application. The steps are to open Script Editor, enter a shell command that runs the Chrome binary with the desired --user-data-dir, save the result in the Applications folder with the file format set to Application, and then run it. The same page describes copying Chrome's icon onto it through the Get Info window so that it looks correct in the Dock. That produces something clickable, pinnable, and launchable from Spotlight, which is as close to a setting as this gets.

A path that does not exist is not treated as an error. Chrome creates it and starts with a completely empty browser: no bookmarks, no extensions, no sign in. That looks exactly like data loss to anyone who mistyped the path, and it is the single most common reason for alarm when trying this for the first time.

What happens after the data lives somewhere else

Beyond the cache, three things change.

Availability becomes conditional. Chromium notes plainly that two running Chrome instances cannot share the same user data directory, and the corollary for a relocated directory is that it has to be present and writable at launch. A disconnected external disk, an unmounted network volume, or a folder that a synchronisation client is in the middle of reconciling all mean the directory is not there, and the wrapper application then opens an empty browser rather than refusing to start.

The file system underneath starts to matter. The profile is a set of databases being written continuously. A volume with different case sensitivity, a network share, or a folder inside a cloud sync directory are all environments where a database can be observed in a half written state by another process. Cloud sync folders are the worst of these, because the client tries to upload files that Chrome holds open, which is a good way to end up with a corrupted profile and a lot of pointless network traffic.

Backups change shape. Anything that used to capture the browser by backing up the library folder no longer does. Whatever tool is in use needs to be told about the new path, and the moment to check that is the day of the move rather than the day of a restore.

Moving existing data rather than starting empty

Pointing the flag at a new path produces a new browser. Carrying the current setup across is a separate job, and the order of operations is what determines whether it works.

Chrome has to be fully quit first, not merely have its windows closed. The profile is a set of open databases, and copying them while the browser holds them produces a copy that may be internally inconsistent. Quitting from the Chrome menu, then confirming that no Chrome process remains, is the prerequisite for everything else.

The copy itself should be a copy rather than a move, at least on the first attempt. Duplicating the user data directory to the new path, launching with the flag pointed at the duplicate, and checking that bookmarks, extensions and sign in state all arrived leaves the original untouched as a fallback. Only after that check succeeds is there any reason to reclaim the space by deleting the original, and there is rarely a hurry.

A tempting alternative is to leave the path alone and replace the folder with a symbolic link pointing at the new location. This makes every launch use the new place, including the Dock icon, which sounds like the setting that Chrome never provided. The trade off is that it is invisible. Nothing in the interface indicates that the folder is a link, backup tools may follow it or skip it depending on their configuration, and a Chrome update or a macOS migration that rebuilds the folder can silently restore the default. It is a working technique for someone who will remember it a year later, and a trap for someone who will not.

Whichever route is chosen, one item does not travel and should be checked afterwards: passwords stored by the system keychain rather than inside the profile remain associated with the login keychain of the macOS user account, so a move between Macs or between user accounts is a different exercise from a move between folders on one machine.

When moving the directory is the wrong tool

Most people arrive at this flag with one of three goals, and only one of them is served by it.

The goal of reclaiming disk space is usually better served by looking at where the space has actually gone. On a Mac in the default configuration, the cache is already outside the profile, under the Caches folder, and it can be cleared without touching bookmarks or sign in state. Moving the whole directory relocates the durable data and, as described above, drags the cache along with it.

The goal of separating work from personal is served by profiles rather than by paths. That is what profiles are for, and it requires no flags, no wrapper applications and no external disks.

The goal that genuinely needs the flag is running a fully independent second Chrome. A separate user data directory gives a separate set of extensions, separate settings, and a separate browser process that can be quit without affecting the first. That is meaningfully different from switching profiles inside one Chrome, where everything shares a single running instance.

Approach	Separate logins	Separate extensions	Separate running process	Effort per launch
--profile-directory	Yes	No	No	A flag or a wrapper
--user-data-dir	Yes	Yes	Yes	A flag or a wrapper
A second macOS user account	Yes	Yes	Yes	Sign in again
One window per web app	Yes	Yes	Yes	None after setup

The last row describes browsers built around aggregation rather than around one tab strip. Each web application gets a persistent window and its own session, so the separation that a second user data directory buys with a launch flag is simply the normal state, and switching between contexts is a click. The category differs on pricing and on how much of the browser is replaced, which is the ground covered in Compared with Wavebox and in Supported apps.

What to change first

Open chrome://version and read the actual Profile Path before changing anything, then decide which of the three goals is really in play. If the aim is space, clear the cache where macOS already keeps it. If the aim is keeping contexts apart every day, a launch flag is a heavy way to get there, and SpaceDeck gives each web app its own window without one.