Import Passwords From Safari to Chrome: Doing It on One Mac

There is no button in Chrome that reaches into Safari and pulls the passwords out. The route exists, it is documented by both companies, and it runs through a single plain text file that sits on the disk for a few minutes and needs deleting afterwards. Knowing that shape in advance makes the job about five minutes long, and knowing what cannot make the trip prevents the quiet failures that show up a week later at a login screen.

Why there is no direct route

Chrome can import some things directly from another browser. Bookmarks, history, homepage and search engine settings are in that group, which is why the Import bookmarks and settings menu item exists and why people reasonably expect passwords to be there too.

Saved passwords sit behind a different boundary. On a Mac they live in the system's own credential store, protected by the account password and, on most machines, by Touch ID. Nothing outside that store gets to read it silently. Google's own instructions for moving passwords into Chrome reflect this: rather than offering a Safari option, the password import page points at export documentation for Safari and other managers and expects a CSV file to arrive from there.

So the operation is deliberately two-sided. Apple decides what leaves, Chrome decides what it accepts, and the file in between is the handover. That design is also why the process involves an explicit warning at each end, which is worth reading rather than clicking past.

Deciding whether to move them at all

Before exporting anything, it is worth separating two different goals that get treated as one.

The first goal is using Chrome as the everyday browser while Safari holds the credentials. That does not require an export. Apple's credential store is available to Safari and to apps that ask for it, and a Chrome user can keep filling logins from Safari's store by hand or by copying an entry when needed. It is clumsy at volume and perfectly workable for a handful of sites, and it involves no unencrypted file at any point.

The second goal is consolidation: one store, in Chrome, so autofill works everywhere without thinking about it. That is the goal the export serves, and it is a real improvement for anyone who has genuinely stopped using Safari. The cost is that the credentials now exist in two places rather than one, because exporting does not remove them from the Passwords app. Duplication is not neutral. Change a password in Chrome six months from now and Safari still offers the old one, which produces exactly the sort of login confusion the consolidation was meant to end.

The third option, which suits a large number of people better than either, is to stop using a browser as the password store at all and put everything in a dedicated manager that both browsers can read. Apple's export and Google's import both exist precisely so that a third tool can sit in the middle, and the CSV route described here is the same route that feeds one.

Whichever goal applies, decide it before the file exists. An export made without a plan tends to sit in Downloads for a year.

Exporting from the Passwords app

On current versions of macOS the export lives in the Passwords app. Apple's user guide for it covers macOS Sequoia 15, macOS Tahoe 26 and macOS 27 Golden Gate.

For the whole collection, Apple's documented steps are: open Passwords, choose File then Export All Passwords to File, click Export Passwords to confirm, then choose where to save the file and click Save. For a single entry the path is nearly identical: select the account, then choose File and Export Selected Password to File, confirm with Export Password, and save.

The file produced is a CSV. Apple attaches an unambiguous warning to it: "Passwords you export are not encrypted and are visible to anyone who has access to the file." The guide instructs you to remove the exported file after importing the passwords elsewhere.

Three kinds of entry do not come out. Apple states that Wi-Fi passwords cannot be exported, that passwords shared through a group cannot be exported unless you created that group, and that Sign in with Apple credentials cannot be exported. The third of those is a category difference rather than a restriction: Sign in with Apple is a token relationship with Apple, not a stored password, so there is nothing to put in a row of a spreadsheet. Any site set up that way will still need Safari or an Apple device to authenticate, whatever Chrome ends up holding.

A practical note on where to save the file. Putting it in the Downloads folder is convenient and forgettable, which is the wrong combination for an unencrypted list of every credential you own. Saving it to the desktop makes it visible, and visible is what gets deleted.

Importing into Chrome

The import lives inside Chrome's password manager rather than in the bookmarks menu, which is the main reason people conclude it does not exist.

Google's documented path on a computer: open Chrome, select More at the top right, then Passwords and autofill, then Google Password Manager, then Settings. Under Import passwords, click Select file, choose the CSV, and follow the on-screen instructions.

Two requirements decide whether the file is accepted. The first is format: Google states that only the .csv format can be imported. The second is the header row. Google's instructions say to check that the first line of the exported file includes the column names url, username and password, and to update the file to include them if it does not. Apple's export produces a CSV with its own header, so in the ordinary case this works untouched, but if the import is rejected the header row is the first thing to look at. A CSV opens in any text editor, and editing the first line is a one-minute job.

Two limits are worth knowing before starting. Google states that 3,000 passwords can be imported at a time, and that a file larger than that must be split into several files imported separately. It also states that up to 10,000 passwords can be stored in a Google Account. Neither figure affects most people, and both matter to anyone consolidating a decade of accounts.

The file is the risk, not the transfer

Both companies warn about the same thing in almost the same words, which is unusual enough to take seriously. Apple's guide says exported passwords are not encrypted and are visible to anyone with access to the file. Google's says that if you do not delete your password file, anyone who uses the device can open the file and access your passwords.

Three habits close the window properly.

• Delete the file the moment the import reports success, and empty the Trash rather than leaving it there.
• Keep the file off any synced folder. A CSV saved into iCloud Drive, Dropbox or Google Drive is copied to a server and to every other device before the import has even finished.
• Do the whole thing in one sitting. The risk is entirely a function of how long the file exists, so an export at lunchtime and an import in the evening is the worst version of this.

There is a fourth habit for shared machines: run the export from an account only you use. On a Mac with several user accounts, a file on a shared volume is not private, and the Trash is per user but a shared folder is not.

What does not come across

The honest summary is that passwords travel and context does not.

Item	Travels through the CSV route
Site passwords stored in the Passwords app	Yes
Usernames and the site addresses they belong to	Yes
Wi-Fi network passwords	No, Apple excludes them from export
Passwords shared through a group you did not create	No
Sign in with Apple relationships	No, there is no password to export
Verification codes and authenticator entries	Not part of the documented password export
Notes and other details attached to an entry	Not guaranteed by a three-column format
Active login sessions	No, a password is not a session

The last row causes the most surprise. Importing a password does not sign you in anywhere. Chrome will offer the credential the next time a login form appears, and any site with two-factor authentication will still ask for a code, and any site that fingerprints devices may treat the new browser as a new device and send a verification email. Budget an hour of that rather than expecting the import to be the end of it.

Bookmarks and history are a separate errand

Passwords and bookmarks travel by different routes, and doing one does not do the other.

For bookmarks, Google's instructions are to follow Safari's own process to save or export bookmarks as an HTML file, then in Chrome select More, Bookmarks and lists, Import bookmarks and settings, choose the file and open it. Google also notes where they land: if Chrome has no bookmarks yet they appear on the bookmarks bar, and if it already has some they arrive in a new folder named Imported.

That two-step nature is worth planning for, because it means a browser move involves two exported files, both of which should be deleted afterwards, and one of which is far more sensitive than the other.

The question underneath the question

Worth asking once the transfer is done: why were two browsers needed in the first place.

For most people the answer is not a preference between rendering engines. It is separation. One browser for the personal accounts and one for work. One for a client's admin console that conflicts with your own. One for the Google account that keeps hijacking the other three. Copying a password store from one browser to the other is a way of making both browsers usable for everything, which solves the symptom by duplicating the credentials into a second place.

There is a structural alternative that removes the reason for the split. A browser that gives each web app its own window and its own cookie container lets several accounts of the same service stay signed in simultaneously, because each workspace is a separate container rather than a tab sharing one session. That removes the usual motive for a second browser, and with it the need to keep two password stores in sync. Tools of that shape that sync their workspace list through your own iCloud or Google Drive, with no vendor account in the middle, also survive a new Mac without a CSV being involved at all. The per-app model is worth a look before repeating this export on the next machine.

What to change first

Do the export and the import in one sitting, delete the CSV and empty the Trash, then check the small number of sites that used Sign in with Apple, since those need Safari or an Apple device regardless of what Chrome now holds. If the real reason for two browsers was keeping accounts apart, fix that with named per-app spaces in SpaceDeck instead of maintaining the same passwords in two places.