Export Chrome Settings: What Can Be Saved and What Cannot

Somewhere in the Chrome menus there ought to be an export settings button that writes one file, and there is not. The search that leads here is usually driven by a deadline: a new Mac arriving, a reimage scheduled, a profile that has started misbehaving and needs rebuilding from a known state. The honest answer is that Chrome exports several things individually, syncs a larger set through a Google Account, and refuses to hand over the rest at all.

Knowing which category each thing falls into is the whole job. Get it wrong and the new machine looks correct for about ten minutes, until the first site asks for a password that is no longer anywhere.

Why there is no single export file

A Chrome profile is not a document. It is a directory holding several SQLite databases, a JSON preferences file, an unpacked copy of every installed extension along with that extension's own storage, a cache, and a set of encrypted blobs whose key is deliberately kept somewhere else on the machine. The Chromium documentation is blunt about what lives there:

The user data directory contains profile data such as history, bookmarks, and cookies, as well as other per-installation local state. Source: chromium.googlesource.com

Per-installation local state is the phrase that decides everything. Parts of that folder are intended to belong to the machine they were created on. An export command would either have to leave those parts out, producing a file that is not really the settings, or include them, producing a file that cannot be trusted on a different Mac. Google's supported answer is to sign into the same account on the second machine and let it rebuild.

On macOS the directory is inside the Application Support folder for Google Chrome, with one subfolder per profile named Default, Profile 1, Profile 2 and so on, plus a JSON file named Local State. Two details matter later. The folder names reflect creation order, not display names, so the third profile ever created is Profile 2 regardless of what it is called in the picker. And the list of which profiles exist, along with their names and avatars, lives in Local State rather than inside the profile folders. To learn which folder belongs to an open profile, go to the version page at chrome://version and read the line labelled Profile Path.

The three exports Chrome does support

Three things can be written to a file and handed to another machine, another browser, or another account.

Bookmarks export to a single HTML file from the bookmark manager: More, then Bookmarks and lists, then Bookmark Manager, then More at the top, then Export Bookmarks. The file is plain text, it opens in any browser, and any browser can read it back.

Passwords export to a CSV file from Google Password Manager: More, then Passwords and autofill, then Google Password Manager, then Settings, then Export passwords, then Download file. The file is unencrypted plain text, which is why the documentation is insistent about deleting it afterwards.

The CSV side has rules worth knowing before the file is handed to anything else. Chrome reads only CSV on the way back in, the first line has to carry the column names url, username and password, and there are ceilings on the operation:

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

Those numbers rarely bite an individual and regularly bite anyone consolidating several profiles into one account. The same page is where passkeys now appear alongside passwords, which matters because a site that has moved to a passkey has no password row to export at all.

Extension lists are not exported as such, but they are recoverable. The extensions page shows what is installed, and each extension has a Chrome Web Store address that can be collected into a plain text list in a couple of minutes. What a given extension has stored inside itself, such as a saved filter set or custom rules, only moves if that extension author chose to sync it.

That is the whole list. Site permissions, search engine entries, startup pages, zoom levels, language settings, toolbar arrangement, and the pinned tabs that make a window feel like the right window have no file format. They either travel through sync or not at all.

What only sync carries

Signing into Chrome puts a published set of categories into the Google Account:

When you sign in to Chrome, on all your devices, you can find your info like: Bookmarks, Reading list, Passwords, Payment info, Identity docs, contact and travel info, and more, Extensions, Web apps, Settings and preferences. Source: support.google.com

Settings and preferences is the entry that answers the original question. The things with no export format are in there, and they arrive on a second Mac signed into the same account. Browsing history and open tabs are governed by a separate switch, under Settings, then You and Google, then the account name, then History and tabs, so a machine that syncs bookmarks correctly can still have an address bar that suggests nothing.

Note what is absent from that list. Cookies are not mentioned, and neither are active sessions. A profile restored entirely through sync is fully furnished and signed out of every site.

A table of where each thing lives

Item	File export	Google Account sync	Survives a folder copy
Bookmarks	Yes, HTML	Yes	Yes
Saved passwords	Yes, CSV	Yes	Usually lost
Payment methods and addresses	No	Yes	Usually lost
Extension list	By hand	Yes	Yes
Data stored inside an extension	No	Only if the extension syncs it	Usually yes
Search engines and startup pages	No	Yes	Yes
Site permissions and zoom levels	No	Yes	Yes
Reading list	No	Yes	Yes
Browsing history	No	With History and tabs on	Yes
Cookies and active logins	No	No	Usually lost
Profile names and avatars	No	Yes	Only with Local State

The two rows that decide the plan are cookies and password encryption. Cookies never move by any supported route, so sessions are always rebuilt by hand. Saved passwords are encrypted with a key held in the login keychain of the Mac that saved them, so they do not travel inside a copied folder. Exporting them to CSV first, or moving the whole user account with Migration Assistant, are the two routes that actually work.

Copying the folder, and when it is worth it

For a profile holding something genuinely hard to rebuild, the folder copy is a real option with conditions attached.

Quit Chrome completely first, not just the window, and confirm in Activity Monitor that no helper processes are left. Those SQLite databases are open while the browser runs, and copying them mid-write produces a profile that opens with a corruption warning and a truncated history.

Then treat Local State as the obstacle it is. Dropping a profile folder onto a new Mac without accounting for it means Chrome never lists the profile in the picker, so the data is on disk and invisible in the interface. The reliable order is to create an empty profile on the new machine first, find the directory it created through the version page, quit Chrome, and replace the contents of that directory with the old profile's contents. Chrome then shows a profile it already knows about, holding the imported data.

Even done correctly, this route arrives logged out and often without saved passwords, for the keychain reason above. It is worth the effort for extension storage and detailed per-site settings. It is not worth the effort for bookmarks, which move in seconds by file.

What to do before wiping the old Mac

Order matters here, because two of these steps are impossible once the machine is gone.

First, list the profiles and their folders. Open each one, visit the version page, and write down the Profile Path next to the account name. Second, export bookmarks to HTML from every profile worth keeping, naming the files after the accounts rather than after the folders. Third, if any profile has a sync passphrase set, resolve it now. The documented consequence of resetting a passphrase is that synced passwords are cleared, and the published order is to export the passwords before the reset and import them again afterwards.

Fourth, export passwords to CSV only if they are not already in a password manager, and delete the file the moment the import on the other side succeeds. Fifth, screenshot the settings that have no export at all: the search engine list, the startup pages, the site permissions that took a while to get right. A screenshot is a poor format and still better than reconstructing from memory.

Putting the settings back

Import is not the mirror image of export, and the asymmetry catches people out. Bookmarks come back through More, then Bookmarks and lists, then Import bookmarks and settings, and the same dialog can pull directly from another browser already installed on that Mac, including Safari and Firefox. Passwords come back through Google Password Manager, under Settings, where an Import passwords control takes the CSV file.

The order to run these in is the order that avoids duplicates. Sign in and let sync finish first, then check what actually arrived, then import only the gaps by file. Doing it the other way round, importing an HTML file into a fresh profile and then signing in, means sync pushes the imported copy up to the account where the originals already are, and every bookmark appears twice on every machine on that account. The same logic applies to passwords: a CSV import into a profile that already syncs passwords produces two rows per site, which then has to be cleaned up entry by entry.

Delete the CSV as soon as the import reports success. The file is plain text with every password in it, readable by anything on the machine, and the documentation treats deleting it as part of the procedure rather than as an optional tidy-up.

The part that migrates every time

Several of the settings worth exporting exist only because one browser is being asked to hold several accounts at once. Profiles are Chrome's answer to that, and they carry a standing cost: one Dock icon for all of them, the same application name in the window switcher, and a check of the avatar before every click that matters. Rebuild them on the new Mac and the cost is rebuilt too.

A different container removes the reason for most of those settings. A browser that keeps each web application in its own window gives Gmail, Slack, and a client dashboard separate windows with separate sessions and separate notification settings, which is usually what the profiles were for. The Workspaces page describes how the sessions are kept apart, Supported apps lists the services set up to run that way, and Compared with Shift sets the options in this category against each other for anyone still choosing.

What to change first

Stop looking for one export file and split the work into three lists: what exports to a file, what only sync carries, and what has to be rebuilt by hand. Do the audit of profiles and folder paths before the old Mac is out of reach, because that is the step nothing can replace afterwards. Then ask how many of those profiles exist purely to keep accounts apart, because that group is what a SpaceDeck style window per application setup makes unnecessary.