Transfer Chrome passwords to another account: the only supported path

Two Google accounts, one browser, and every saved login sitting in the wrong one. A work account gets created, or a personal account gets retired, and the passwords stay where they were first typed. Chrome has no button labelled "move these passwords to that other account", so the search ends up being for a workaround, and the internet offers several that either do not exist any more or quietly lose data.

There is one route Chrome supports, and it runs through a file on disk. Everything else is either a different question in disguise, such as moving between two profiles on the same Mac, or a third-party tool doing the same export and import with a friendlier screen. Knowing which of those applies saves an hour of clicking through settings pages looking for an option that was never there.

Three different questions hide behind one sentence

"Another account" means at least three different things, and the answers do not overlap.

Another Google Account. Passwords saved while signed in to one Google Account live in that account's Google Password Manager. A second account has its own separate store. Nothing in Chrome merges them, and signing in to both at the same time is not possible within one profile.

Another Chrome profile on the same computer. This is a local question. Chrome keeps a separate profile directory per person, each with its own password store, and Chrome has an import path for pulling data from another browser or profile on the same machine.

Another computer or another user account on the Mac. Here the passwords may not need moving at all. Signing in to the same Google Account on the new machine and turning on sync brings them across, because the store is attached to the account rather than to the installation.

There is a fourth case that looks like the second and is not. A Chrome profile signed in to a Google Account and a Chrome profile with no account attached behave differently: the signed-in one keeps its passwords in the account's store, while a local profile keeps them on the machine only. Moving from a local profile to an account, or the reverse, is the CSV route even though both profiles sit on the same Mac, because there is no second browser for the import dialog to read from.

Only the first case genuinely needs the file route. The second has a built-in path. The third usually needs no transfer at all. Sorting this out first prevents exporting a plain text file for no reason.

The supported route is a file, and the file is plain text

The path Chrome supports between two Google Accounts is an export from the first and an import into the second. The password manager lives at its own address, chrome://password-manager, with export and import under its settings.

The sequence is short. Sign in to the account that holds the passwords, open the password manager settings, and export. macOS asks for authentication before the file is written, because Chrome treats creating a readable copy of every saved password as an operation that needs the device password or Touch ID. Then sign out, sign in to the second account, open the same settings page, and import the file. When the import would overwrite credentials that already exist in the destination account, macOS asks for authentication again before replacing them.

What comes out is a CSV with five columns: name, url, username, password, and note. The password column is the password, in readable text, with no encryption and no passphrase. Chrome's own source comments note that metadata are lost in the conversion, so what survives is the credential itself rather than the history around it.

The import side has a limit worth knowing before the file is produced: Chrome rejects a CSV larger than roughly one megabyte. That is thousands of entries rather than hundreds, so most people never meet it, but a store carrying long notes on every entry can cross it. Splitting the file into two and importing each half in turn is the fix, and the import screen reports which rows it refused rather than failing silently.

The import screen is more informative than most people expect, and it is worth reading rather than closing. Chrome validates each row and reports the ones it would not accept: an entry with no password in it, a URL it cannot parse, and any field longer than the limit it enforces for usernames, URLs, or notes. A row rejected for one of those reasons is simply not imported, and the rest of the file still lands, so a partially reported import is not a reason to start over. Fixing the named rows in the CSV and importing the file a second time adds only the missing ones.

Profile to profile on the same Mac

When both identities already exist as Chrome profiles on the same machine, there is a shorter path. Chrome's import dialog for bookmarks and settings includes a checkbox for saved passwords alongside favourites, history, and search engines, and it reads from another browser or profile installed locally rather than from a file.

This route never writes credentials to disk in readable form, which is the main reason to prefer it. It is also limited to the same computer: the source has to be installed and readable on the machine doing the import. A profile that only exists on a laptop three hundred miles away is not a candidate.

The distinction matters because the two routes are often described interchangeably in forum answers. An answer telling someone to use the import dialog is correct for two local profiles and useless for two Google Accounts, and the person asking rarely says which situation they are in.

What the file does not carry

A CSV export is a list of credentials. Several things people expect to travel with their passwords are not credentials.

Passkeys are not in the file. They are key pairs held by the authenticator that created them, on the device or in the account that owns them, and a list of username and password columns has no way to express one. Accounts that were switched over to passkeys have to be enrolled again on the new account, which is a per-site operation on each site.

Two-factor settings do not move either. Recovery codes, authenticator app enrolments, and trusted-device flags belong to each site's account rather than to the browser, so a successful password transfer still means re-approving a login on every site that asks for a second factor.

Sessions do not move. Cookies stay with the profile, so the destination account starts signed out of everything even though it now knows all the passwords. That is the part that makes the day after a transfer feel like the transfer failed when it actually worked.

Payment methods and addresses stored for autofill are held separately from passwords and are not part of a password export. And the note column travels, but only up to Chrome's own length limit for notes, with anything longer reported as a rejected row rather than truncated quietly.

Compare the routes before picking one

Route	Works between two Google Accounts	Writes passwords to disk	Needs both on one machine
Export and import a CSV	Yes	Yes, in readable text	No
Chrome import dialog, saved passwords	No, local profiles only	No	Yes
Sign in and sync on the new machine	No, same account only	No	No
A separate password manager	Yes, via the same CSV	Usually briefly	No

The last row deserves a plain statement rather than a recommendation. Third-party password managers accept the same Chrome CSV, and several publish import instructions for exactly this file. What that buys is a store that is not attached to one Google Account, so the next identity change is a matter of signing in rather than exporting again. What it costs is a subscription in most cases and a new piece of software in the login path. Both are defensible, and neither is the browser's decision to make.

Handle the file as the risk it is

Between the export and the import there is a plain text list of every password on a disk, and treating it casually is the real failure mode of this whole procedure.

Write it somewhere deliberate rather than accepting the default, keep the window of exposure to the few minutes the import needs, and delete it immediately afterwards. Emptying the Trash matters as well, because a file in the Trash is still a file. On a Mac with backups running, a file that sits in a backed-up folder long enough gets copied into the backup set, where deleting the original does not reach it, so the short window is doing real work and not just satisfying a checklist.

An export is also the only time the whole list is readable in one place, which makes it the one good moment to prune. A store that has been accumulating since 2014 usually contains dead sites, duplicate entries for the same service under two usernames, and half a dozen passwords that were rotated years ago on the site but never updated in the browser. Deleting those rows from the CSV before importing means the new account starts with a store that reflects reality, instead of carrying the old one's clutter forward for another decade. Sorting the file by the url column groups the duplicates together and makes the pass quick.

Cloud sync folders deserve the same caution. A CSV dropped into a synced folder for convenience is uploaded within seconds, and pulling it back down from three devices and a web trash bin afterwards is a worse job than the transfer itself. A local folder outside any sync path is the boring correct answer. Sending the file to yourself by email is the version of this that ends up permanently in a mail archive.

The reason this keeps coming up

The underlying problem is not the export dialog. It is that one browser window has to be one identity at a time, while the work being done spans several. A person with a personal account, a company account, and a client's account is not going to stop needing all three, and profile switching turns every context change into a window dance with a real chance of typing into the wrong one.

That is the argument for keeping each account and each web app in its own separate workspace with its own session instead of arranging them as tabs in a single profile. When the tools are separated by window rather than by which profile is currently active, a second Google Account stops being a thing to migrate to and becomes just another space that stays signed in, and the list of apps that get their own space covers the accounts most people juggle.

What to change first

If the transfer is between two Google Accounts, do the CSV route once, deliberately, and delete the file the moment the import reports its results. If both identities live on the same Mac, use the import dialog instead and keep the passwords off the disk entirely. Then consider whether the accounts need to keep taking turns in one window at all, because a setup like SpaceDeck that gives each account its own space removes the reason for the next export.