Move every Chrome profile to another Mac

A new Mac arrives and Chrome installs in about a minute. Then the actual work starts. The old machine has five profiles on it. One for personal mail, one for the day job, one for the client whose Google Workspace account refuses to sit quietly next to anything else, one for testing, and one nobody remembers creating. The Chrome menu has no command that packages those five up and hands them over. Searching for one produces folder paths and warnings, which is the correct answer, just not the one that was wanted.

The reason there is no export command is worth understanding before touching anything, because it decides which of the two real routes is right for each profile.

A profile is not a document

Bookmarks export to an HTML file. Passwords export to a CSV file. A profile exports to nothing, because a profile is not one thing. It is a directory holding several SQLite databases (history, cookies, form data), a JSON preferences file, an unpacked copy of every installed extension along with that extension's own storage, a cache, and a set of encrypted blobs whose decryption key is deliberately stored somewhere else on the machine.

The Chromium documentation is blunt about what that directory is:

The user data directory contains profile data such as history, bookmarks, and cookies, as well as other per-installation local state. Source: chromium.googlesource.com

Per-installation local state is the phrase that matters. Parts of it are meant to be tied to the machine it was created on. Google's supported answer for getting a profile onto a second computer is to sign into the same Google Account there and let sync rebuild it. Every other approach is a file copy that Chrome makes no promise about.

Both routes work. They just carry different things, and mixing them up is what produces the classic result: the new Mac opens a profile that looks correct, has the right bookmarks, the right avatar, the right extensions, and is signed out of every single site.

Where the profiles actually live

Everything sits in one folder on macOS:

~/Library/Application Support/Google/Chrome/

Inside it are directories named Default, Profile 1, Profile 2, Profile 3 and so on, plus Guest Profile, System Profile, and a file called Local State.

Two details trip people up here. The first is that the directory names are creation order, not identity. Profile 3 is simply the fourth profile ever made on that Mac. It has no relationship to whatever it is called in the profile picker.

The second is that the display names, the avatars, and the list of which profiles exist at all are not stored inside the profile directories. They live in Local State, a JSON file, under a key named profile.info_cache. Copy a profile folder to a new Mac without dealing with Local State and Chrome will not show it in the picker at all. The data is present on disk and invisible in the interface.

To find out which folder belongs to which profile, open a window in that profile and go to chrome://version. The line labelled Profile Path names the directory. Doing this once per profile and writing the results down takes a couple of minutes and prevents the most common mistake in the whole operation, which is copying the wrong folder and only finding out a week later.

What sync carries and what it leaves behind

Signing into the Google Account on the new Mac and turning sync on rebuilds a great deal. It also silently skips the part most people were counting on.

Item	Chrome sync	Copying the folder
Bookmarks	Yes	Yes
History	Yes	Yes
Saved passwords	Yes, on the same account	Usually lost
Autofill and payment methods	Yes	Usually lost
Extension list	Yes	Yes
Data stored inside an extension	Only if that extension syncs it	Usually yes
Open tabs and reading list	Yes	Yes
Cookies and active logins	No	Usually lost
Site permissions, zoom levels, per site settings	Partly	Yes
Profile name and avatar	Yes	Only with Local State

The row that decides everything is cookies. Chrome sync does not sync cookies, by design. So a synced profile arrives fully furnished and logged out. For a profile with three or four sites in it, that is fifteen minutes of signing in and it is over. For a profile holding a dozen internal tools, each with its own single sign on flow and its own hardware key prompt, it is an afternoon.

The other row worth reading twice is extension data. The list of extensions syncs. What a given extension has stored locally, such as a saved configuration or an ad blocker's custom rules, only comes across if the extension author chose to sync it. Many did not.

Copying the folders by hand

For profiles worth the trouble, the copy route works, with conditions.

Quit Chrome completely first. Not the window, the application, and then confirm no Google Chrome Helper processes are left in Activity Monitor. Those SQLite databases are open while Chrome runs, and copying them mid write produces a profile that opens with a corruption warning and a truncated history.

Then choose one of two approaches.

Copying the whole Chrome folder

The simplest option, and the one that avoids editing JSON. Set up the new Mac, launch Chrome once so the folder structure exists, quit it, then replace the entire ~/Library/Application Support/Google/Chrome/ directory with the one from the old machine. Every profile, and the Local State that describes them, arrives together and matches.

The cost is that it overwrites anything already created on the new Mac. If the new machine has been in use for two weeks and has its own profile with its own bookmarks, that profile is gone. This route belongs at the very start of a migration, not in the middle of one.

Copying individual profile folders

Copy Profile 2 across on its own, and Chrome will not list it. The fix is to create a new empty profile on the new Mac first, note which directory it created through chrome://version, quit Chrome, and replace that directory's contents with the old one. Chrome already has a Local State entry pointing at the folder, so the imported data appears under the placeholder profile's name, which can then be renamed.

Editing profile.info_cache in Local State by hand also works and is faster for six profiles, but it means editing JSON that Chrome rewrites on every launch, so the edit has to happen while Chrome is fully quit.

Why the copied profile is signed out

This is the part that surprises people, and it is not a bug.

On macOS, Chrome encrypts saved passwords and the cookie store with a key kept in the login keychain, under an entry called Chrome Safe Storage. The key is not inside the profile folder. It never was. Move the folder to another Mac and the encrypted blobs travel with it while the key stays behind, so Chrome finds password entries it cannot read and session cookies it cannot decrypt. The profile opens, everything visual is intact, and every site asks for a login.

Three practical consequences follow.

Exporting passwords before the move is the reliable path. In Chrome, open chrome://password-manager/settings and choose Export passwords. What comes out is a plain CSV file with every password readable by anyone who opens it, so it goes on the internal disk, gets imported on the new Mac, and gets deleted immediately afterwards. Do not park it in a shared folder or a downloads directory that syncs to cloud storage.

Migration Assistant is the exception that keeps everything. Because it moves the whole user account, including the login keychain, a full transfer preserves the passwords and the active sessions that a manual folder copy destroys. If the goal really is all five profiles exactly as they were, and the new Mac is still at the setup screen, that is the tool for it.

Sessions protected by a hardware security key or a device bound passkey are not recoverable by any file copy. Those are tied to the machine on purpose, and re registering on the new Mac is the only route.

Extensions are the part worth checking twice

The extension list comes back through sync, but an extension is two things: the code, and whatever that extension has written into its own local storage. A password manager restores from its own account and does not care. A tab manager, a clipping tool, or a request interceptor with a hand built rule set may hold everything locally, and a synced profile brings back the extension with an empty configuration.

The check takes a minute per extension. Open its options page on the old Mac and look for an export or backup command. Many have one, producing a small JSON file. Extensions with no export are the strongest argument for copying that profile's folder rather than trusting sync, because the alternative is rebuilding a configuration nobody wrote down.

Deciding profile by profile

Before any of this, the useful question is which profiles actually earn a move. Most sets of five contain two that matter.

A short test works well. Open the profile picker on the old Mac and, for each profile, answer three things. Was it opened in the last month. Does it hold extension configuration that would be tedious to rebuild. Is it separate from the others only because two Google accounts refuse to share a window.

A profile that exists purely to keep two Google accounts apart is cheap to recreate. Sign in on the new Mac, let sync fill it, spend ten minutes on logins, done. A profile with a carefully tuned set of extensions and years of site permissions is worth the folder copy and the password export. A profile that has not been opened since spring is worth nothing at all, and moving it just carries the clutter forward. Migration is the one moment when deleting is free.

Fewer profiles is also an answer

The reason for five profiles is rarely five browsing identities. It is usually a handful of web applications that will not coexist in one window, sitting behind accounts that will not coexist in one session.

Chrome profiles solve that, at a cost that becomes visible on the new Mac. Every profile is a separate window of the same application. They share one Dock icon, they all answer to the same name in Command Tab, and switching between them means the profile picker or a keyboard shortcut and a mental note about which window is currently which account. That cost is paid every day, while the migration is paid once.

A different container answers the same problem in a different shape. A browser that keeps each web application in its own window gives Gmail, Slack, and a client dashboard separate windows with separate sessions and separate notification settings, which is what the profiles were being used for in the first place. The Workspaces page describes how the sessions are kept apart, and Supported apps lists which services are set up to run that way. For anyone weighing this against the tools already in the category, Compared with Wavebox sets the differences out side by side.

What to change first

Do the audit before the copy. Write down each profile's directory from chrome://version, mark the two that hold something genuinely hard to rebuild, and let sync handle the rest on the new Mac. Then, once the migration is done, look at how many of those profiles exist only to keep two accounts apart, because that is the group a SpaceDeck style window per application setup removes entirely.