Export Google passwords before a switch: the safe order

The request to export Google passwords almost never arrives on its own. It shows up in the middle of something larger: a move to a different password manager, a new Mac being set up, a work account being separated from a personal one, or a decision to stop keeping credentials inside a browser. The export itself takes about fifteen seconds. The part that deserves attention is what exists on disk immediately afterwards, and for how long.

The file Chrome hands over is a plain text spreadsheet containing every site, username and password in the account, with no password on the file itself. That is not a flaw in the feature. It is the only format a competing password manager can read. It does mean the export should be the last step taken rather than the first, and that the destination should be ready before the file exists.

What the export actually produces

On a computer, the control is labelled "Export passwords" and the result is a .csv file. A CSV is a text file. Opening it in any text editor shows the URL, the username and the password for every entry, in order, readable by anyone who can open the file. There is no encryption layer, no passphrase prompt, and no expiry.

Apple states the same thing in its own Passwords guide, in language worth reading twice before clicking anything:

WARNING: Passwords you export are not encrypted and are visible to anyone who has access to the file. After you import the passwords into another password manager, delete the file you exported.

Two consequences follow from that, and both are about location rather than technique.

The first is that the default download folder is the wrong destination if the Mac syncs that folder to a cloud service. A file placed in a synced Desktop or Downloads folder is copied off the machine within seconds, into a service that keeps version history. Deleting the local copy later does not reliably remove the copies that were made in between. Exporting to a location that is not synced avoids the problem entirely.

The second is that the file belongs in the Trash and then out of it. Moving a CSV of credentials to the Trash and leaving it there for a week is functionally the same as leaving it on the Desktop. Google's own import instructions treat this as a numbered step rather than an afterthought: the documented sequence is to export from the other app, import into Google Password Manager, and then delete the .csv password file on the device.

The exact path in Chrome

The menu wording has changed more than once, which is why older guides send people to settings pages that no longer exist. The current documented route on a computer is short.

Open Chrome. At the top right, select More, then Passwords and autofill. Select Google Password Manager, then Settings. Scroll to "Export passwords" and select Download file.

Typing chrome://password-manager/settings into the address bar lands on the same screen without the menu walk, which is useful when the toolbar has been customised. On Chromium-based browsers the equivalent is the same scheme with that browser's name, and Microsoft Edge keeps the export behind an overflow menu in the saved passwords section rather than exposing it directly.

Expect an authorisation prompt. The browser asks for the macOS account password, or the screen lock, before it will write the file. That prompt is the only thing standing between a borrowed, unlocked Mac and a full credential dump, which is a good reason to check whether "Use your screen lock when filling passwords" is switched on in the same Settings screen. It is off by default.

The export does not remove anything. The passwords stay in the Google account and stay in Chrome after the file is written. Migrating away is therefore a two-part job: export and import, then separately delete the originals. The same Settings screen carries a "Delete all Google Password Manager data" control for that second part, and it should only be used once the destination has been verified.

The order that keeps the exposure window short

Most of the risk in this operation comes from doing the steps in the wrong sequence, which leaves the CSV sitting around while something else is figured out.

The sequence that keeps the file alive for the shortest time is to install and sign in to the destination manager first, locate its import screen and confirm which formats it accepts, then create the export, then import immediately, then delete the file, then verify. Verification is worth doing before the originals are deleted: open three or four accounts of different kinds in the new manager, including one long random password and one entry that has a note attached, and confirm the values are intact.

Duplicate handling is the step most people get wrong. Bitwarden's documentation is explicit that importing does not check for duplicates, so importing the same file twice, or importing entries that are already in the vault, creates duplicate items. Apple's Passwords app behaves differently: imported passwords do not replace passwords already present, and the app surfaces a list of any entries that could not be imported so they can be reviewed.

Once the import is verified, delete the CSV, then empty the Trash. Apple's import flow even offers this as a button: after a successful import, the app presents a Delete option for the file that was just read.

Where the file can go

The CSV format is the common currency between managers, but the import path differs. The table below reflects each vendor's published instructions.

Destination	Import route	Notes on behaviour
Apple Passwords on Mac	File > Import Passwords from File, then Choose File	Imports do not replace existing entries; offers to delete the source file afterwards
Bitwarden	Tools > Import, choose file format, then Choose File	No duplicate checking; data is encrypted locally before upload
Google Password Manager	Settings > Import, after exporting from the other app	Documented as a three-step flow ending in deleting the .csv

Apple's Passwords app is the option most Mac users already have and most overlook. It requires the passwords from the other app to be in a CSV file, which is exactly what Chrome produces, and the whole route is File > Import Passwords from File, then Choose File, then Import.

Bitwarden adds one route the others do not: its desktop app can import directly from a Chromium browser without an intermediate file at all. Where that path is available it is strictly safer, because no plaintext CSV is ever written to disk.

Passkeys do not travel the same road

This is the detail that catches people mid-migration. On a computer, the export control is labelled "Export passwords" and produces a .csv. On iPhone, iPad and Android, Google Password Manager offers something different: an "Export data" flow where individual passwords or passkeys are selected and handed to a destination app directly, app to app, with no file in between.

That difference matters when the goal is to leave Google Password Manager completely rather than just take a copy of the passwords. A passkey is a key pair bound to the device and the service, not a string that can be typed into a spreadsheet cell, which is why the transfer is an app-to-app handover rather than a CSV row. Anyone who has been using passkeys for a few services should plan to do that part of the move from a phone, and should expect some entries to need re-registration on the service's own site regardless.

Google also notes that imports can arrive incomplete. Sign-in data with invalid or missing mandatory fields lands on an "Invalid Data" screen listing what did not come across, and app or site names do not always map into the correct field, so an entry that appears to be missing is often findable by searching for the site name rather than the app name. The same caution applies in reverse when importing a Google export elsewhere.

A migration is the only good moment to prune

Everyone imports the whole file and intends to clean it up later. Later does not arrive, and the new manager inherits a decade of dead entries along with the live ones.

The export is the one moment when the entire credential list is visible as a flat list rather than as a search box, which makes it the cheapest time to cut. Open the CSV in a spreadsheet, sort by site, and three categories usually stand out. There are entries for services that no longer exist. There are duplicates of the same site under two slightly different URLs, one of which stopped autofilling years ago. And there are entries where the username column holds an address that was abandoned, which means the credential is unusable even if the password is correct. None of those need to make the journey.

Chrome has a tool that identifies a fourth category. In Google Password Manager, selecting Checkup reports which saved passwords have been exposed in a data breach and which are weak and easy to guess. Running that before the export turns the migration into a shortlist of passwords that should be changed at the source rather than copied intact into a new vault. Changing a breached password on the site itself, then exporting, means the new manager starts with a value that is actually current.

One caution about editing the file. A CSV of credentials open in a spreadsheet application is the same exposure as the file itself, plus whatever autosave and recent-documents behaviour that application has. Make the cuts, save back to CSV, import, and then delete both the CSV and any working copy the spreadsheet created.

The other half of a switch is sessions, not passwords

There is a reason a password migration often feels only half finished. Passwords are the credentials. Sessions are what is actually keeping anyone signed in.

A browser profile holds cookies, tokens and site data, and one profile can hold exactly one signed-in session per service at a time. Moving passwords into a new manager does nothing to that layer. After a clean export and import, the second Google account, the second Slack workspace and the second Notion login are all still competing for the same cookie jar, which is why the switching continues even though every credential is now safely stored and autofilling correctly.

Tools built for that layer give each web app its own window and its own session store, so two accounts on the same service stay open side by side without either one logging the other out. A feature overview is the quickest way to see which of those session capabilities exist, and the list of supported apps shows whether the specific services in daily use are covered. Worth being clear about the division of labour: a password manager holds the credentials, and this layer holds the logged-in state. Neither replaces the other.

What to change first

Do the destination first. Install the password manager that will hold these credentials, find its import screen, and only then run the export in Chrome, so the CSV exists for minutes rather than days. Delete the file and empty the Trash before deleting anything on the Google side.

If the switching that prompted this was really about being signed in twice to the same services rather than about where passwords live, the layer to change is the window, and SpaceDeck is organised around that. The pricing page shows what the free plan covers before anything is installed.