Export Chrome Passwords: The Steps Before You Move to a New Mac

The request usually arrives with a deadline attached. A new Mac is being set up, a password manager is being adopted, or a work profile is being handed back, and the hundreds of logins sitting inside Chrome have to come out in a form something else can read. The export itself takes about twenty seconds. Everything around it, deciding where the file goes, what it exposes while it exists, and what it quietly leaves behind, is the part worth getting right.

Google documents the whole path, but the menu names have shifted enough over the past few years that older instructions send people to settings screens that no longer exist. What follows is the current route, the limits Google publishes for the file, and the destinations that accept it today.

The export moved into Google Password Manager

Chrome no longer keeps passwords in a page of browser settings. They live in Google Password Manager, which Chrome opens as its own surface, and the export is a button inside that surface rather than a menu item in Chrome itself.

Google's instructions for showing, editing, deleting, or exporting saved passwords give the route in four moves. Open Chrome, select More at the top right, then Passwords and autofill, then Google Password Manager. On the left, select Settings. On the right of Export Passwords, select Download file.

The separate help page on importing and exporting with Google Password Manager describes the same destination with one extra scroll: More, then Passwords and autofill, then Google Password Manager, then Settings, then scroll to Export passwords and select Download file. Either description lands in the same place. macOS will ask for the account password or Touch ID before the file is written, because the system treats reading the stored credentials as a request for the keychain rather than a file download.

One detail decides how much the export actually contains. Google describes two storage locations: passwords saved to a Google Account, which follow the signed-in profile across devices, and passwords saved to the device when Chrome is not signed in. An export reflects what the current profile can see. A Mac with three Chrome profiles has three separate exports, and running the steps once produces one of them.

The file is plain text, and that is the whole risk

What downloads is a CSV file. Not an encrypted archive, not a vault, not something that asks for a password when opened. Any text editor shows every site, every username, and every password in readable columns.

Google's documentation treats that plainly rather than burying it. Its import instructions include a step titled delete your .csv password file on your device, with the reason stated directly: if the file is not deleted, anyone who uses the device can open it and read the passwords. Apple uses the same framing in the Passwords app, where the export page warns that exported passwords are not encrypted and are visible to anyone who has access to the file, and instructs deleting the file after the import is finished.

Three practical consequences follow from that. The file should not be written to a synced folder, because Desktop and Documents may both be in iCloud Drive, which turns a local file into a copy on every signed-in device. It should not be emailed to the new Mac, since mail keeps copies in sent items and on the server. And deleting it means emptying the Trash, not dragging it there.

The format is also stricter than it looks. Google's import guidance says the first line of the file must include the column names url, username, and password, and that a file lacking them needs editing before it will import. A CSV exported from Chrome already satisfies this. A CSV that has been opened in a spreadsheet, edited, and saved again sometimes does not, which is the most common reason an import is refused.

Where the file can go next

The CSV is a transfer format, not a storage format, which means the export is only half a job. The destination decides the rest, and each documented target has its own path and its own published limits.

Destination	What it accepts	Documented behaviour
Google Password Manager	CSV with url, username, password columns	3,000 passwords per import, up to 10,000 stored in a Google Account
Passwords app on macOS	CSV from another passwords app	Imported passwords do not replace existing ones, and any that fail can be reviewed
Microsoft Edge	Passwords CSV file	Imported passwords are added to the existing saved passwords
Another password manager	Varies by product	Follow that product's own documentation

Google's own numbers are worth knowing before a large export is attempted. Its import and export page states that 3,000 passwords can be imported at a time, that larger sets need splitting into several CSV files, and that a Google Account stores up to 10,000 passwords. It also warns that not all app and site names land in the correct field, and suggests searching by app or site name when an imported entry cannot be found.

For a Mac that is standardising on Apple's own tools, the Passwords app import route is File, then Import Passwords from File, then Choose File, then Import, followed by a prompt to delete the file. Apple states that imported passwords will not replace passwords already held, and that entries which could not be imported can be reviewed afterwards. Edge accepts the same file through Settings, then Profiles, then Import browser data, choosing Passwords CSV file under Other import locations.

What the export does not carry

A CSV of site, username, and password is a smaller thing than the browsing life it was extracted from, and the gap explains most of the disappointment that follows a migration.

Passkeys are a different object. Google's help page covers both passwords and passkeys under one title, and Google Password Manager stores both, but a passkey is a key pair bound to hardware and to the account that holds it rather than a string that can be typed into a column. An export of passwords does not turn a passkey into a portable secret.

Active sessions do not travel either. Passwords let a browser fill a form. They do not reproduce the state of being logged in, which is a cookie, and they do not reproduce the second factor, which is usually a trusted device. A new Mac with every password imported still faces a verification prompt on each service that uses one, and that is the part of a migration that actually consumes an afternoon.

Two more categories fall outside the file. Apple's Passwords app notes that Wi-Fi passwords, passwords shared with a group created by someone else, and access to Sign in with Apple accounts cannot be exported, so an export from that side is not complete either. And nothing about a password export reproduces the arrangement of the browser: profiles, pinned tabs, extensions, and which window held which account. Those are described in Chrome's own sync documentation as things tied to a signed-in account, not to a file.

Signing in is a different mechanism from exporting

Half the people who look for the export do not need it, and the distinction is worth five minutes because it changes what has to be carried by hand.

Chrome's documentation for getting bookmarks, passwords, and more on all devices lists what a signed-in profile keeps in a Google Account: bookmarks, reading list, passwords, payment info, extensions, web apps, and settings and preferences, with tabs and browsing history available as a separate switch. Signing into the same account on a new Mac pulls that set down without a file existing at any point.

The same page states the reverse case just as clearly. When Chrome is signed out, bookmarks and other information are saved only on the device and not in the Google Account, and a prompt under the profile menu offers to save existing items into the account. A Mac where Chrome was never signed in has nothing waiting in the cloud, which is exactly the situation where a CSV is the only route.

There is one more wrinkle for anyone who has set a sync passphrase. Google describes a passphrase as optional and as a way to store Chrome data in its cloud without Google being able to read it, and notes that the passphrase is required to sign in to Chrome with that account on a new device. A forgotten passphrase turns a sync-based migration into a manual one, so it belongs in the same note as the export.

The honest summary is that the export exists for crossing boundaries: to a different password manager, to a different account, or to a Mac that will deliberately not be signed into Chrome. Within one account on two Macs, signing in does the same job with no plaintext file to clean up afterwards.

Doing it as part of a move to a new Mac

Order matters here, because two of the steps are irreversible and one of them is usually done too early.

Export while the old Mac is still fully set up, before Migration Assistant runs and well before the old machine is erased. Apple's guidance for transferring to a new Mac lists documents, apps, user accounts, and settings as what moves, and notes separately that email transfers but the email account might need setting up again in the email app. Credentials are treated differently from files throughout that process, so the export exists precisely to cover what the migration does not.

Then decide whether the file is needed at all. Signing into the same Google Account on the new Mac's Chrome brings saved passwords with it, which is the path Google documents for getting bookmarks, passwords, and more on all devices. The CSV becomes necessary when the destination is a different manager, a different account, or a Mac that will not be signed into Chrome at all.

If the file is needed, write it to a folder that is not synced, complete the import on the new Mac the same day, delete the file, and empty the Trash on both machines if it was copied across. Apple's notes on what to do before selling or giving away a Mac cover the erase step afterwards, which is the point of no return for anything still sitting on the old disk.

The sprawl an export makes visible

Anyone who opens their own exported CSV tends to find the same thing: far more rows than expected, several of them for the same service under different accounts. A work Google account and a personal one. Two Slack workspaces. A client's project tool and an internal one. Three logins for the same cloud console.

That is not untidiness, it is what the working day looks like now, and it is the reason a password import does not finish the job. Chrome answers multiple accounts for one service with profiles, each in its own window, each with its own set of saved passwords and its own export. The arrangement works and it is also the thing nobody can reconstruct from memory a year later.

A setup where each web app sits in its own persistent space, with its own cookie container, treats the same problem from the other end: three accounts for one service can be signed in at once without any of them seeing the others, and the list of workspaces is the thing that gets carried between Macs rather than an undocumented pile of browser profiles. For a machine being rebuilt anyway, that is the cheapest moment to decide which shape the next two years of logins will take.

What to change first

Export the CSV, import it into its destination the same day, then delete the file and empty the Trash. After that, spend the ten minutes the migration has already interrupted on the arrangement rather than the credentials: give every service that has more than one account its own window with its own container, which is what SpaceDeck keeps once the passwords are back in place.