Copying a Google Chrome profile on a Mac

Copying a Chrome profile sounds like copying a folder, and on macOS it literally is one. The reason it goes wrong is that the word covers at least four different tasks with four different outcomes, and the method that works for one produces a broken result for another. Getting the intent right before touching the file system saves the hour usually spent wondering why the duplicated profile is signed out, or why bookmarks started appearing in two places at once.

Four different tasks share the same phrase

The first is duplication on one machine. A profile has been set up carefully with extensions, bookmark folders, a search engine, and a set of pinned tabs, and a second one is wanted with the same setup but a different account. Nothing leaves the Mac.

The second is migration. The same profile has to exist on a different Mac, or in a different macOS user account on the same Mac. The folder crosses a boundary that the encryption does not cross with it.

The third is partial transfer. Only the bookmarks are needed elsewhere, or only the saved passwords, or only the list of extensions. This is the most common actual need hiding behind the word copy.

The fourth is backup. A snapshot is wanted before an experiment, so that the previous state can be restored if the experiment goes badly.

These four differ in one respect that decides everything: whether the copy stays inside the same macOS user account. Inside it, encrypted data remains readable. Across it, the encrypted data becomes noise. Everything below follows from that single line.

Where the files are, and which file is the index

Chrome keeps everything under one directory on macOS. The Chromium documentation lists the location for each channel, with the stable release at ~/Library/Application Support/Google/Chrome. Inside that directory, each profile is its own subfolder, and the same documentation notes that a profile is a subdirectory, often named Default, within the user data directory.

The naming is the first trap. Folder names run Default, Profile 1, Profile 2 and upward in creation order, and they have no relationship to the display names shown in Chrome. Deleting a profile does not renumber the rest, so a Mac with five visible profiles can easily hold folders numbered up to nine. Reading chrome://version inside a given profile's window and looking at the Profile Path line is the only reliable way to tie a name to a folder.

The second thing in that directory is a file named Local State, which sits beside the profile folders rather than inside them. It holds the list of profiles Chrome believes exist, along with each one's display name, avatar, and signed-in account. This file, not the folders, is what the profile menu reads. A profile folder copied into place without a matching entry in Local State simply does not appear anywhere in the interface, which is the single most common reason a copy seems to have failed when the data is sitting there intact.

Chrome must be fully quit before any of this is touched. Chrome writes to these files continuously, and copying them while it runs produces a mixture of two states. Closing every window is not enough on macOS if the application is still running in the Dock, so quitting through the menu or with ⌘ + Q is the step to take, followed by a glance at Activity Monitor for any leftover Google Chrome Helper processes.

Inside a profile folder, a few files carry most of what people actually care about. Bookmarks is readable JSON and can be inspected in any text editor, with Bookmarks.bak sitting beside it as the previous version. History, Cookies, Login Data, and Web Data are SQLite databases, and the last two hold values encrypted rather than in plain text. Preferences and Secure Preferences hold the settings for that profile, including which extensions are enabled. Knowing which file is which turns a copy into a decision about what to bring rather than a single all-or-nothing move.

Cloning a profile on the same Mac

Cloning inside one macOS user account is the case that actually works cleanly, because the encryption key does not move. The Chromium project describes the component that handles this as providing cryptographic primitives that allow binding data to the OS user:

This directory contains OSCrypt implementations that support cryptographic primitives that allow binding data to the OS user. Source: chromium.googlesource.com

Bound to the OS user means that a copy landing in the same OS user account can still be decrypted. Saved passwords and cookies survive. A copy landing in a different user account, or on a different Mac, cannot be decrypted, and Chrome responds by treating the saved passwords as unreadable and the sessions as signed out.

The working sequence for a clone is to create the destination first rather than inventing it. Add a new profile through Chrome's own profile menu, open chrome://version inside that new profile to read which folder it was given, then quit Chrome completely. Replace the contents of that new folder with the contents of the source profile folder, leaving Local State alone, and reopen Chrome. The new profile keeps its own name and avatar from Local State while carrying the source profile's data.

Copy scenario	Bookmarks and history	Extensions	Saved passwords	Logged-in sessions
Clone in the same macOS user	Carried	Carried	Carried	Carried
Copy to another macOS user	Carried	Carried	Unreadable	Signed out
Copy to another Mac	Carried	Carried	Unreadable	Signed out
Sign in and let sync rebuild	Carried	Carried	Carried	Signed out

The problem a clone creates on the second day

A clone works, and then a specific kind of mess begins, because the source profile was almost certainly signed in to a Google account and the clone now carries that same signed-in state.

Two profiles signed in to one Google account, both with sync turned on, both write to the same account. Bookmarks created in one appear in the other. An extension installed in one installs itself in the other. A bookmark folder reorganised in one gets reorganised in the other. This is sync doing exactly what it promises, applied to a situation it was not meant for.

The fix is to break the link immediately after cloning, before opening anything else. Turn sync off in the clone, sign out of the Google account, then sign in with the account the clone is actually for. What remains is the local setup, the extensions and the preferences, which was the point of cloning in the first place.

There is a quieter version of the same problem. A cloned profile carries the source profile's session cookies, so the clone opens already logged in to every web service the source was logged in to. Anyone who then signs the clone into a second account on those services ends up with two profiles holding overlapping logins and no visual difference between the windows. Setting a distinct profile colour and avatar before doing any work is a small step that prevents a long-running category of mistake.

Copying only the parts that matter

For most of the situations that lead to this search, the whole folder is more than is needed, and the pieces move through supported routes with none of the encryption problem.

Bookmarks export to a single HTML file from the bookmark manager, and import from the same file into any profile, any browser, and any machine. Passwords export to a CSV file from Chrome's password settings, which is plain text and should be deleted the moment the import finishes. Extensions do not move as files in any useful way, and the practical approach is to write down the list and reinstall from the store, which also removes anything that stopped being maintained.

What has no supported export is browsing history, open tab state, and site permissions. Those either come across in a full folder copy inside the same OS user, or come from sync, or do not come at all.

There is a middle path worth knowing about for the backup case. Duplicating the profile folder to an external drive while Chrome is quit produces a snapshot that can be dropped back in later, on the same Mac and the same user account, with everything intact including sessions. This is the cheapest way to experiment with a risky extension or a settings change, and it is far more reliable than trying to undo the change afterwards. Time Machine does the same job on a schedule, with the caveat that restoring a single profile folder means quitting Chrome first and restoring the whole folder rather than individual files inside it, since the SQLite databases and their write-ahead logs have to match.

Sync deserves a mention as the sanctioned path for the migration case. Signing in on the destination and letting it pull bookmarks, passwords, extensions, and settings avoids the encryption problem entirely, because each machine encrypts locally with the key held by its own OS user. It does not carry cookies, so every service asks for a login once, which is a few minutes of work rather than a broken profile.

What a copy does not give

There is an assumption worth naming, because a lot of profile copying is done in service of it. Separate profiles are often treated as a security boundary between people or between jobs. Chrome's own documentation is direct about what they are not:

Only share your device with people you trust. If someone has your device, they can switch to any other Chrome profile on it. If they open your Chrome profile, they can see info like what websites you visited. Source: support.google.com

Profiles separate data. They do not lock it. Anyone at the keyboard can open any profile on the machine, which means a cloned profile carrying a client's live sessions is a copy of that access, not a sandboxed version of it. Where a real boundary is required, the tool is a separate macOS user account, which is protected by the login password and by a different encryption key.

The other thing a copy does not give is fewer things to manage. Each clone adds a window to keep track of, a set of extensions to update, a signed-in account to remember, and one more place a message might arrive. The switching cost that made the setup feel worth duplicating grows with every duplication.

What to change first

Decide which of the four tasks is actually in play, then take the matching route. For duplication on one Mac, create the destination profile in Chrome first, quit fully, swap the folder contents, then immediately sign the clone out of the source account. For a move to another machine, use sync and accept the logins. For anything partial, export the bookmarks and passwords rather than the folder.

Then count how many profiles exist purely to hold one more account of one more service. If that number keeps climbing, the copying is a symptom, and giving each web app its own window with its own session removes the reason to clone at all. SpaceDeck is built that way, and the services already set up for it are listed under Supported apps.