Moving Passwords Out of Your Browser, Step by Step

Last updated: October 29, 2026 · Based on published browser and manager documentation

Browser password storage has improved to the point where it is no longer the worst option available, and it remains the most common one because it is already there. Moving to a dedicated manager is a genuine improvement for anyone who uses more than one browser or more than one device, but the export and import step is where people get stuck, and the mistakes made during it are the ones that end up in a password manager as permanent data. This guide works through the migration properly, including what to do with the entries that will not survive the trip.

Table of contents

• What you gain by leaving the browser
• Before you export: inventory first
• Exporting from each browser
• The entries that will not migrate cleanly
• Importing, and what to verify afterwards
• Switching the browser over
• Deleting the old copy properly
• FAQ
• Bottom line

What you gain by leaving the browser

Browser storage has one structural weakness that no amount of improvement removes: it is tied to one browser profile on one device. That produces three specific limitations.

• No portability. Credentials saved in one browser are not in another, and not on your phone. If you use two browsers at work, or a laptop and a phone, you are maintaining the same set of logins twice, and one of those copies is usually out of date.
• No sharing that is safe. A shared browser profile shares everything, including accounts that have nothing to do with the person you share it with.
• All-or-nothing clearing. Clearing browser data is a single action that removes every saved credential at once, with no per-item control.

A dedicated manager inverts this. One vault, available on every device and in every browser through an extension, with per-item sharing and per-item deletion. The cost is that you now have a single place where losing the master password matters a great deal, which is the trade-off to understand before you move rather than after. The framework in choosing a password manager covers how to weigh that against the alternatives.

Before you export: inventory first

Exporting first and tidying afterwards means you carry a mess across and then clean it in the new system, where you may not recognise what each entry is. Inventory first instead.

• Export a copy now, before you touch anything. This is the safety net for the whole procedure. Keep it somewhere you will not lose it, and do not delete it until the new system has been verified for a while.
• Look at the count, and look at the shapes. How many entries, and how many of them are the same site recorded twice with slightly different addresses? A large number of entries for one domain usually means several accounts, which is worth knowing about before you start tidying.
• Note the sites you will not miss. There will be entries for things you have not used in years. Do not migrate them deliberately; decide what to do with them rather than dragging them along.
• Identify the important ones. Your email, your bank, your domain registrar, and the place that holds the password reset for everything else. These need to be verified carefully after the move, and they are the ones where a failed import is genuinely painful.
• Check whether you use the browser's own sync. If credentials are syncing between browsers today, that sync will keep them arriving after you have migrated unless you turn it off. This is the single most common cause of duplicates persisting after a move.

Exporting from each browser

The route differs by browser, and the output format differs too. In all cases the export contains the site address, the username, the password and, usually, some metadata.

Chrome and Edge are Chromium-based and share a route: the password manager settings page, then the three-dot menu, then “Export passwords”. This produces a CSV file. [VERIFY the exact menu path in your browser version, as it has moved between releases.]

Firefox exports from the logins page, and the export dialog offers a format choice. The formatted file and the plain-text file are not the same, and which one a given manager imports cleanly varies, so it is worth checking the import options before choosing.

Safari exports passwords from the Passwords section of the system settings, again to a CSV.

Two practical warnings. First, **the export file is unencrypted and contains every password you have saved** — treat it as a live credential file, not as a document. Keep it on an encrypted volume, and delete it when you are done. Second, **check whether you have a master password or a device passcode protecting the browser store**; if the browser was unlocked by anyone with the device, the export contains those too.

The entries that will not migrate cleanly

Most entries transfer without trouble. The ones that cause trouble fall into a few recognisable types, and handling them deliberately is what makes the difference between a clean vault and one you distrust.

• Duplicate site entries. The same domain saved several times with different usernames, or the same credential saved under both http:// and https:// or with and without a www. prefix. These are common and harmless, but there are usually far more of them than people expect.
• Entries with no URL. Some saved items are local or application entries with a blank or malformed address. Most managers cannot match these to a site, so they arrive as untitled records you will have to identify by hand.
• Entries whose password was never actually saved. Some browsers store the site and username but not the credential, for a login where you chose not to save. These arrive without a password.
• Long strings that are not passwords. Occasionally a saved value is a reference code, a serial number, or a pasted block of text. These look like passwords and will be autofilled into the wrong field.
• Old shared items. Credentials shared with someone years ago, or with an account that no longer exists.

Importing, and what to verify afterwards

Import is usually a single operation and usually works. The part that matters is what you do next.

1. Import into a fresh vault, not an existing one. Importing into a vault you already use makes duplicate handling much harder. Start clean.
2. Do not delete the browser copy yet. Leave it in place while you verify. Deleting it early is the step that cannot be undone.
3. Install the manager's browser extension on the browser you use most. The extension is what provides autofill and the save prompt; without it, the import is inert.
4. Test the important logins one at a time. Log into your email, your bank, your registrar. Confirm both that the credential works and that autofill offered it on the right site rather than something else.
5. Test the save prompt on a site you do not have an entry for. This is the step most people skip, and it is the one that determines whether the manager stays current.
6. Check the one with the duplicate entries. Find a site you had saved several times and confirm the manager picked a sensible one. If it picked badly, fix that entry before you start relying on autofill everywhere.
7. Look for the untitled entries and resolve them. Every record you cannot name is a record you will not recognise later. Either complete it or delete it.
8. Wait a week before removing the browser copy. A week of ordinary use surfaces the sites you actually use and the ones you thought you used.

Switching the browser over

Once the manager is working, the browser's own store should be turned off so it stops accumulating new entries and stop syncing the old ones.

• Turn off the browser's built-in save prompt. Otherwise you will be asked on every login, and habit will win.
• Turn off browser sync of passwords. This is the setting that keeps re-adding what you just removed.
• Delete the browser's saved passwords. Only after the week of verification.
• Check whether the browser's own password change prompt still fires. Some browsers offer to update a saved password when you change it on a site. With the manager installed, you want that in one place only.
• On a shared machine, check the profile you were using. If the browser had more than one profile, each may hold its own store.

Deleting the old copy properly

• Delete from every browser that held a copy. This includes browsers on other devices and any old laptop you still have.
• Empty the browser's trash and confirm. Some browsers keep deleted passwords recoverable for a period.
• Check the operating system's own store. Windows and macOS both keep a credential store, and a browser may have populated it.
• Delete the export file, and empty the recycle bin. It contained every password in plaintext.
• Change the passwords for the accounts that were on shared or compromised devices. A migration is a good moment to do this, because you are touching those entries anyway.

FAQ

Is the browser's built-in storage good enough?

For a single browser on a single device, for someone who does not share credentials and does not need them on a phone, it is more capable than its reputation suggests. The reasons to move are portability, safe sharing and per-item control — not any inherent weakness in how it stores things. That assessment is worked through in choosing a password manager.

Do I have to migrate everything?

No. Migrating the sites you actually use and leaving the rest behind is a perfectly good outcome, and leaving stale entries behind has its own benefit: an account you have not touched in years is one you are not exposed to through a forgotten password sitting in an old store.

What if I lose the master password after migrating?

This is the risk the move creates, and it should be managed deliberately rather than hoped away. Set up the recovery options the manager offers, keep an offline recovery kit somewhere physically secure, and set an emergency contact if the manager supports it. The mechanism is explained in shared vaults and family security.

Can I have the manager and keep browser storage as well?

You can, and you should not. Two stores mean two copies, one of which drifts, and every login has a coin toss about which one autofills. Pick one, and if the manager's extension is not working on a given site, fix that rather than reverting.

Does importing expose my passwords to the vendor?

A properly implemented manager encrypts the vault with a key derived from your master password, which means the vendor cannot read the contents of an exported file you import. This is worth verifying for the specific product before you import, since the claim matters and the implementations differ — choosing a password manager sets out what to look for.

Bottom line

The migration itself is a thirty-minute job if you do it in the right order, and a weekend if you do it in the wrong one. Inventory first and keep the export as a safety net. Import into a clean vault, install the extension, and verify the important logins one at a time along with the save prompt on a new site. Leave the browser copy alone for a week, then turn off the browser's own saving and sync before deleting what it held. The payoff is not that the passwords are safer in one place — it is that they are in one place, portable, and shareable on your terms.

If you have chosen a manager and want to see current pricing, the link below goes to our own page for the category.

See current password manager plans →