Chrome Passwords Import: Bringing a CSV Back Into the Browser

There is a CSV file sitting in the Downloads folder, exported from Safari, from a password manager, or from Chrome on a machine that is about to be wiped. The task is to get those rows back into Chrome on this Mac. The control exists, it is not on the settings page most people look at first, and it has a few rules that reject a file without explaining much.

The part that causes real damage is not the import itself. It is importing into a profile that is already syncing, which produces two entries for every site and a cleanup job that has to be done one row at a time.

Where the import control actually lives

Password handling moved out of Chrome's main settings page some time ago. The route is More at the top right, then Passwords and autofill, then Google Password Manager, then Settings. The import control sits on that Settings page, and the documented wording is direct:

Under "Import passwords," click Select file. Choose the .csv file you want to import. To complete your import, follow the on-screen instructions. Source: support.google.com

Two things about that page are worth noting. It is the same page that holds the export control, so the round trip happens in one place. And Chrome's password store is Google Password Manager, which is reachable in a browser at the passwords.google.com address as well as inside Chrome, so an import done here shows up there once the profile is signed in.

The older advice about enabling a hidden flag to make an import button appear is out of date. That flag existed for a period when the feature was being rolled out, and the supported control is now on the Settings page permanently. Anyone following an old forum thread into the experiments page is looking for something that has been removed.

The file has to be CSV, with the right header

Chrome accepts exactly one format, and it checks the first line before it does anything else.

Important: You can only import passwords in the .csv file format to Google Password Manager. Source: support.google.com

The header row is the part that trips up files exported from other tools. Chrome looks for the column names url, username and password on the first line, and a file whose columns are named differently has to be edited before it is accepted. Opening the file in a plain text editor and correcting the first line is enough. There is no need to reorder the columns themselves.

Two common shapes cause trouble. Some exports use a single header like Login URI or Web Site instead of url. Some spreadsheets, when a CSV is opened and saved again, rewrite the file in a way that changes the quoting or the line endings, which is a good reason to edit the header in a text editor rather than in a spreadsheet. Note also that an encrypted export, such as a password manager's own backup format, is not a CSV and cannot be imported. The export has to be the unencrypted CSV option.

The file is plain text with every password in it. That is true from the moment it is written until it is deleted, and the documentation treats deleting it as part of the procedure rather than as an optional tidy-up. Anything else on the Mac that can read the Downloads folder can read the file, and so can a backup running in the background.

The published limits

Two numbers govern how large an import can be:

You can import 3,000 passwords at a time. If you must import more, split them into multiple .csv files and import the files separately. You can store up to 10,000 passwords in your Google Account. Source: support.google.com

A personal collection rarely comes close. Two situations do. One is a consolidation, where several profiles or several old machines are being folded into a single account. The other is a shared collection inherited from a team tool, where entries have accumulated for years. In both cases the file has to be split, and splitting it in a text editor by line count is safer than splitting it in a spreadsheet.

The 10,000 figure is the ceiling on the account, not on the import, and it applies to the total after the import lands. Hitting it is a signal that the collection needs pruning rather than a larger file.

Import before sync, not after

This is the step order that decides whether the result is clean.

A profile signed into a Google Account with passwords syncing already holds whatever that account holds. Importing a CSV into it adds rows without merging them, so a site that exists in both places ends up with two entries, distinguishable only by which password is current. Chrome does not offer a merge review. The documentation notes a related annoyance, which is that not every app and site name lands in the correct field, so the imported row may not even sort next to its twin.

Order of operations	Result
Sign in, let sync finish, then import only the missing sites	Clean, one row per site
Import the whole CSV, then sign in and sync	Duplicates, pushed to every device on the account
Import twice by mistake	Two copies of everything imported
Import into a profile that is not signed in	Stored on the device only, until the profile is signed in

The last row is a useful option rather than a mistake. A profile that has never been signed in stores passwords locally on the device, and they can be moved into the account later. That is the route for anyone who wants the passwords available in the browser without putting them in a Google Account at all.

If duplicates have already happened, the cleanup is manual: open Google Password Manager, sort by site, and delete the stale row of each pair. There is no bulk de-duplicate function. Doing the pruning before the import is considerably less work than doing it after.

Getting the file out of the other tool first

An import is only as good as the export that fed it, and the export is where most of the lost rows happen.

For Chrome on another machine, the export is on the same Google Password Manager settings page, under Export passwords, and it writes the file straight to disk. For Safari, for Edge, and for the major password managers, the export lives in that application's own settings rather than in Chrome, and Google's import page links out to instructions for several of them rather than describing them, because the menus move.

One case deserves its own warning. If the source profile has a sync passphrase set, resetting or forgetting that passphrase clears the synced passwords, and the published order of operations is to export the passwords before the reset and import them again afterwards. Doing it the other way round means the export runs against an account that has already been emptied, and the file comes out with far fewer rows than expected. The count is the tell, so open the file and count the lines before trusting it.

It is also worth opening the file once in a text editor regardless of source. A row whose password field is empty, a row whose url field holds an application name rather than an address, and a file that turned out to contain 40 rows instead of 400 are all visible in a few seconds and invisible after the import.

Passkeys change the shape of the problem

The support page covering this has widened from passwords to passwords and passkeys, and that matters for anyone auditing what actually moved.

A site that has been switched to a passkey has no password row to export, so it will be absent from the CSV, and its absence is correct rather than an export failure. On a new machine that site is signed into with a passkey held by the device or the account, not with anything in the file. Checking the list of sites in the file against the list of sites actually used is therefore worth ten minutes, because a site that was expected in the CSV and is missing is usually one that moved to a passkey rather than one that was lost.

Two-factor prompts behave the same way regardless of how the password arrived. An imported password gets past the first screen and nothing more. Any site protected by an authenticator app or a hardware key still asks for the second factor on the new machine, because that step was never in the file.

After the import: the check, and the delete

Run three checks in order. Open Google Password Manager and confirm the count went up by roughly the number of rows in the file. Spot check five entries, preferring sites whose names came through oddly, and confirm the username field holds a username rather than a site name. Then sign into two of those sites to confirm the passwords are the current ones and not an older generation from a stale export.

Then delete the CSV, empty the Trash, and check whether anything copied it in the meantime. A file in the Downloads folder may already be in a cloud sync folder or a Time Machine snapshot, and a plain text file of every password in a backup is a longer lived problem than the original import.

One last thing worth doing at the same time. Chrome can flag entries that are exposed in a known breach or trivially weak, and an import is the natural moment to run that check, because the rows that just arrived are frequently the oldest ones in the collection.

When several accounts are the actual problem

A surprising share of password imports exist because one browser is being asked to hold several identities. A personal account, a work account and a client account each need their own saved logins, so the collection gets split across Chrome profiles, and each profile needs its own import when a machine changes. The profiles then share one Dock icon and one application name, and knowing which window belongs to which account is a check performed before every click that matters.

A different container removes the reason for most of that. A browser that keeps each web application in its own window gives Gmail, Slack and a client dashboard separate windows with separate sessions, so two accounts on the same service coexist without a profile switcher and without one shared password list to keep untangled. The Workspaces page describes how the sessions are isolated, and Supported apps lists the services set up to run that way. For a straight comparison against the other tools in the category, Compared with Ferdium lays out the differences.

What to change first

Fix the header row before anything else, because a file whose first line does not name url, username and password is rejected without much explanation. Then decide the order deliberately: sign in, let sync finish, and import only the gaps, rather than importing everything and letting sync duplicate it. Delete the CSV the moment the count checks out, and then look at how many profiles exist only to keep accounts apart, since that is the group a SpaceDeck style window per application setup removes.