Chrome Export of Passwords and Bookmarks: Two Files, Two Risks

Asking Chrome for passwords and bookmarks in one go feels like one task, and Chrome treats it as two. The bookmarks come out of the bookmark manager as an HTML file. The passwords come out of Google Password Manager as a CSV file. Different menus, different formats, different destinations on the other side, and only one of the two is dangerous to leave lying around.

That asymmetry is the useful thing to understand before starting, because it decides the order of the steps and what has to be cleaned up afterwards. A bookmarks file is a list of public addresses. A passwords file is every credential in readable text.

Bookmarks leave through the bookmark manager

The bookmarks route has not moved in years, which is why it is the easier half. Google's instructions for moving or exporting bookmarks to another browser are: open Chrome, select More at the top right, then Bookmarks and lists, then Bookmark Manager. At the top, select More, then Export Bookmarks.

Chrome writes an HTML file. Google's own description of it is that the file is used to import bookmarks into another browser, and that is precisely what it is: a single document listing every bookmark with its title, its address, and the folder structure around it. Opening it in a browser shows a plain page of links, which is a fast way to confirm the export worked before anything is erased.

The same page covers the other direction. To bring bookmarks in, select More, then Bookmarks and lists, then Import bookmarks and settings, then Choose file. Where they land is documented and worth knowing in advance. If the destination copy of Chrome had no bookmarks, the imported ones appear in the bookmarks bar. If it already had bookmarks, they are added to the Other bookmarks folder at the end of the bar rather than merged into the existing structure.

Other browsers state their own behaviour. Microsoft's instructions for importing favorites and passwords into Edge say that a Favorites or bookmarks HTML file is chosen under Other import locations, and that the imported favourites appear in a folder on the Favorites bar which may be named Imported. Apple's Safari documentation for importing from another browser says it can read bookmarks exported in HTML format from Firefox, Edge, Chrome, and some other browsers, and that imported bookmarks appear after the existing ones. In all three cases the import adds, it does not replace, so running one twice leaves duplicates rather than overwriting anything.

Passwords leave through Google Password Manager

Passwords are not in Chrome's settings pages any more, and instructions written before that change send people hunting through the wrong screen. Google's current route, given on its page for showing, editing, deleting, or exporting saved passwords, is More at the top right, then Passwords and autofill, then Google Password Manager, then Settings on the left, then Download file to the right of Export Passwords.

macOS asks for the account password or Touch ID first, because the request reads stored credentials out of the keychain rather than copying a file. What arrives is a CSV, and Google's import and export documentation confirms the shape it expects in the other direction: the first line of the file must include the column names url, username, and password.

That page also sets the two ceilings anyone moving a large collection needs. Up to 3,000 passwords can be imported into Google Password Manager at a time, with larger sets split into several files, and a Google Account can hold up to 10,000 passwords. It adds one caveat about accuracy: not every app or site name arrives in the correct field, and a missing entry is often findable by searching the app or site name rather than the address.

Which passwords are in the file depends on which profile ran the export. Google describes two storage locations, a Google Account for a signed-in profile and the device itself when Chrome is signed out, and the export covers what the active profile can see. A Mac running separate work and personal Chrome profiles has two exports to do, not one.

The two files compared

	Bookmarks	Passwords
Menu	Bookmark Manager, then More, then Export Bookmarks	Google Password Manager, then Settings, then Download file
Format	HTML	CSV
Contents	Titles, addresses, folder structure	Site address, username, password in readable text
Authentication to export	None	Mac account password or Touch ID
On import	Added alongside existing items, never replacing	Added alongside existing items, never replacing
Documented limits	None published	3,000 per import, 10,000 stored per Google Account
After the import	Keep it as a backup if useful	Delete the file, then empty the Trash

The last row is the one that matters. Google's import instructions include a step titled delete your .csv password file on your device, with the reason given plainly: if the file is not deleted, anyone who uses the device can open it and read the passwords. Apple's Passwords app repeats the point on its export page, warning that exported passwords are not encrypted, are visible to anyone with access to the file, and should be deleted once the import is done.

Two habits follow. Do not write the CSV into Desktop or Documents if those folders are in iCloud Drive, because that turns one local file into a copy on every signed-in device. And do not send it to the new machine by email, since copies stay in sent items and on the mail server after the original is deleted.

Sometimes neither file is needed

Both destinations that most Mac users are moving toward can read Chrome directly, without any file being written, and that route skips the plaintext CSV entirely.

Apple's documentation for importing into Safari describes two moments. The first time Safari opens after Chrome or Firefox has been in use, a message at the bottom of the start page offers to keep the imported items, and Safari's wording covers bookmarks, history, and passwords. Later, the same import runs from File, then Import From Browser, then Google Chrome. Two conditions apply: Chrome has to be installed on that Mac for the direct import to work, and imported passwords go into iCloud Keychain rather than a file, so they are usable for autofill straight away.

Edge offers the equivalent. Microsoft's page lists importing from another browser installed on the same machine as the first option, with the HTML and CSV file routes grouped separately under Other import locations for cases where the source browser is not present.

The condition in both cases is that both browsers are on the same Mac. That is true when a browser is being changed, and false when a machine is being changed, which is the situation that forces the two files into existence. It is worth checking which of the two situations applies before exporting anything, because a direct import carries bookmarks and credentials in one pass and leaves nothing on the disk to clean up.

There is a third case. When the destination is the same Google Account on a new Mac, signing into Chrome brings bookmarks, passwords, payment info, extensions, web apps, and settings down without an export at all. The files matter when crossing an account boundary, a product boundary, or a machine boundary with nothing installed on both sides.

What neither file carries

Between them the two exports cover a browser's public list and its secrets, and still leave out most of what makes a working setup feel like itself.

Extensions are not in either file. Google lists extensions among the things a signed-in Chrome keeps in a Google Account, alongside bookmarks, passwords, payment info, web apps, and settings and preferences, which means they arrive by signing in rather than by importing anything. A machine deliberately kept signed out needs them installed again by hand, and their own settings usually start empty.

Sessions are not in either file. A password lets a browser fill a form. Being logged in is a cookie, and a trusted second factor is a property of the device, so a new Mac holding every password still faces a verification prompt on each service that uses one. That is the step that turns a fifteen minute import into a long afternoon.

Passkeys are a third object again. Google Password Manager holds them and its help page covers them alongside passwords, but a passkey is a key pair tied to hardware and to the account that stores it, not a string that fits in a CSV column. Apple's Passwords app is explicit about its own gaps in the other direction, stating that Wi-Fi passwords, passwords shared with a group created by someone else, and access to Sign in with Apple accounts cannot be exported at all.

Finally, neither file records the arrangement. Which profile held the work account, which windows were open, which app lived where. That information exists only in the habits of the person using the machine, which is why a fully imported browser can still feel wrong on day one.

Doing both in one pass

Sequence matters more than speed, because two of these steps cannot be undone once the old Mac is erased.

Export the bookmarks first. It needs no authentication, it produces a file that is safe to keep, and opening it in a browser confirms immediately that the export is complete rather than empty. Do this for each Chrome profile that matters, and rename each file as it is written, since every export arrives with the same default name.

Export the passwords second, one profile at a time, into a folder that is not synced. Import them on the destination the same day, whether that destination is Google Password Manager, the Passwords app on macOS through File, then Import Passwords from File, or Edge through Settings, then Profiles, then Import browser data. Then delete the CSV and empty the Trash on both machines.

Only then deal with the machine itself. Apple's guidance for transferring to a new Mac covers documents, apps, user accounts, and settings, and notes separately that email transfers but the account may need setting up again in the email app. Credentials are handled differently from files throughout that process, which is the reason these two exports exist as a separate job rather than as part of the migration.

The multi-account problem the exports expose

Anyone who opens their own CSV finds the same surprise: several rows for the same service, under different accounts. Two Google accounts, two Slack workspaces, a client's project tool and an internal one, three logins for one cloud console. The bookmarks file shows the matching pattern, with near-duplicate links pointing at the same tool under different tenants.

Chrome's documented answer to that is profiles, one window each, each with its own passwords and therefore its own export. It works, and it also means a migration has to be run once per profile, and that nothing written down explains which profile was which.

Keeping each web app in its own persistent space with its own cookie container attacks the same problem from the other side. Three accounts for one service stay signed in at once without seeing each other, and what gets carried to the next Mac is a named list of workspaces rather than a pile of profile folders nobody can identify. The moment when both files are sitting on the desktop is the cheapest time to decide whether that shape is worth adopting.

What to change first

Run the bookmarks export, confirm it by opening the HTML file, then run the passwords export, import it the same day, delete the CSV and empty the Trash. With the credentials handled, give each service that has more than one account its own window and its own container, which is the arrangement SpaceDeck is built to hold once the importing is finished.