Export From Google Password Manager: What to Do Before Switching Macs

The plan is simple enough: pull the saved logins out of Chrome, take them somewhere else, and stop relying on one browser to hold every account. The control for that is real and it takes about thirty seconds to use. What takes longer is understanding what comes out of it, because the file is narrower than most people expect and the timing of the export decides whether it is complete.

Two things go wrong often enough to be worth naming up front. Exporting after a sync passphrase has been reset produces a file with a fraction of the rows. And the file itself is plain text with every password in it, sitting in the Downloads folder, where a backup or a cloud sync folder can pick it up within minutes.

Where the export control is

It is not on Chrome's main settings page. The route is More at the top right, then Passwords and autofill, then Google Password Manager, then Settings. The documented steps are short:

On your computer, open Chrome. At the top right, select More Passwords and autofill. Select Google Password Manager Settings. Scroll to "Export passwords." Select Download file. Source: support.google.com

Chrome asks for the Mac's login credentials before it writes anything, which is the operating system confirming that the person at the keyboard is the account holder. That prompt is not optional and cannot be skipped from a script.

The same collection is reachable outside Chrome at the passwords.google.com address, which matters for anyone who has stopped using Chrome as a daily browser but still has years of logins in the account. The store belongs to the Google Account, not to the browser installation, so the export can be run from any machine signed into that account.

What the file contains, and what it does not

The export is a CSV whose useful columns are the site address, the username, and the password. That is the whole payload. Several things people assume are in there are not.

Item	In the export file
Site address, username, password	Yes
Notes attached to an entry	No
Passkeys	No, they are not passwords
Two-factor codes and authenticator seeds	No
Payment methods and addresses	No
Site cookies and active sessions	No
Which Chrome profile the entry came from	No

The passkey row is the one that has changed recently. The support page covering this is now titled for passwords and passkeys together, and a site that has been switched to a passkey has no password row to export. Its absence from the file is correct rather than a failure, and mistaking one for the other leads to a long search for rows that were never there.

The profile row matters for anyone running several Chrome profiles. Each profile is tied to at most one Google Account, and the export runs against the account behind the profile it was started from. Exporting from the work profile produces the work account's passwords and nothing from the personal one. Collecting everything means running the export once per profile and keeping the files clearly named, because the files themselves carry no hint of which account they came from.

Check for a passphrase before exporting

This is the step that decides whether the file is complete, and it is easy to get in the wrong order.

Some accounts have a sync passphrase set, which encrypts the account data with a secret Google does not hold. The consequences are published, and one of them concerns exactly this operation:

When you have a passphrase: You need it to sign in to Chrome with your Google Account on a new device. You need to enter it on your devices where you're already signed in. You can't check your saved passwords on passwords.google.com or use Smart Lock for Passwords. Source: support.google.com

So on a passphrase account the web route is unavailable and the export has to be run inside Chrome on a device where the passphrase has already been entered. More importantly, resetting a forgotten passphrase clears the synced passwords, and the documented order is to export the passwords before the reset and import them again afterwards. Running it the other way round means exporting an emptied account.

The check is simple. Open Settings, then You and Google, then the account name, then Encryption options. If a passphrase is set, export first and change nothing until the file has been counted.

Count the rows before trusting the file

An export that silently returns fewer rows than expected is the quiet failure in this whole procedure, and the only defence is to look at the file.

Open it in a plain text editor rather than a spreadsheet. Confirm the first line names the columns. Count the lines and compare that against the number of entries shown in Google Password Manager, allowing one line for the header. A file with 40 rows where the manager listed 400 means the export ran against the wrong account, against a profile that was not the intended one, or against an account whose passwords had already been cleared.

While the file is open, scan for two specific defects. Rows with an empty password field, which come from entries saved as usernames only. And rows whose address field holds an application identifier rather than a web address, which come from passwords saved by an Android or iOS app rather than by the browser. Neither will import cleanly anywhere, and both are easier to fix in the file than in the destination.

Avoid opening the file in a spreadsheet application if it can be helped. Saving from a spreadsheet rewrites quoting and line endings, and a password containing a comma or a quotation mark can come out of that process changed.

What the account holds besides passwords

Deciding what to export means knowing what else is in the account, because the password list is one category among several and the others move differently.

Chrome's published list of what a signed in browser keeps in the Google Account covers bookmarks, the reading list, passwords, payment information, extensions, web apps, and settings and preferences, with browsing history and open tabs governed by a separate switch. Only two of those have a file export at all: bookmarks, which come out as an HTML file from the bookmark manager, and passwords, which come out as the CSV described here.

Payment methods and addresses are the category people most often assume travel with the passwords. They do not appear in the CSV, and on an account with a sync passphrase they sit outside that encryption entirely, because Google Wallet holds them separately. The practical consequence is that a machine switch which relies only on the password export arrives with every login available and every stored card gone.

Two-factor settings are a separate matter again. Nothing in the export re-establishes them, so a list of which accounts use an authenticator app, and which use a hardware key, is worth writing down by hand before the old machine is out of reach. That list takes ten minutes to make and saves an afternoon of recovery flows.

The file is a liability from the moment it exists

There is no password on the export. There is no expiry. It is a text file, and anything that can read the folder can read every credential in it.

The documentation is direct about the last step of the process:

Important: If you don't delete your password file, anyone who uses the device can open the file and access your passwords. Source: support.google.com

Three practical consequences follow. Write the file somewhere outside the synced folders, because a Downloads folder inside a cloud service means the file has left the machine before it has been used. Finish the import on the destination the same day rather than leaving the file for the weekend. And after deleting it, empty the Trash and consider whether a backup snapshot has already captured it, since the copy in a backup outlives the deletion.

For a transfer between two machines on the same desk, a direct copy is better than a network round trip. Moving the file on a cable or over a local transfer keeps it off any server that is not needed. Sending it to an inbox, even a private one, puts a permanent copy of every credential in a mail archive that is backed up and searchable for years, which is the one route worth ruling out completely.

Where the passwords should land

The export is a means, not a destination, and the destination shapes how the file should be handled.

Moving to a dedicated password manager is the common case, and every mainstream one accepts a CSV import. Moving to Apple's Passwords app keeps the credentials inside the system keychain and available to Safari and to applications. Moving to another Chrome profile or another Google Account uses the import control on the same page the export came from, where the ceilings are three thousand rows per file and ten thousand stored per account.

One destination deserves a note. Importing into a profile that already syncs passwords for the same sites adds rows instead of merging them, so the result is two entries per site with no bulk way to reconcile them. Signing in, letting sync settle, and importing only the gaps avoids that.

The reason the collection got this big

Most oversized password collections are a record of one browser being asked to hold several identities. A personal account, a work account, and a client account each accumulate their own logins for the same handful of services, so the list fills with near duplicate entries for the same site under different addresses, and the only thing distinguishing them is which profile happened to be in front at the time.

A different container changes that arithmetic. A browser that keeps each web application in its own window holds Gmail, Slack, and a client dashboard as separate windows with separate sessions, so two accounts on the same service stay apart without a profile switcher and without one shared credential list carrying the burden. The Workspaces page sets out how the sessions are kept separate, and Supported apps lists the services already configured to run that way. For anyone comparing tools in this category before committing, Compared with Sidekick puts the differences side by side.

What to change first

Check for a sync passphrase before touching anything, because resetting one clears the synced passwords and the export has to come first. Then export, count the lines against what Google Password Manager lists, finish the import the same day, and delete the file and empty the Trash. Once the credentials are somewhere durable, the profiles that exist only to keep accounts apart are the ones a SpaceDeck style window per application setup makes unnecessary.