Bookmarks gone after switching Chrome accounts

The bookmarks bar is empty, the folders are gone, and the last thing that happened was a click on the profile icon in the top right corner of Chrome. Anyone trying to restore a Chrome profile on a Mac at this point usually starts by searching for recovery software. That is the wrong first move. Chrome does not store bookmarks per Google account. It stores them per profile, in a separate folder on disk, and switching profiles shows a different folder. Most of the time nothing was deleted. The job is to work out which folder is currently on screen, and only then decide whether a restore is needed.

What a Chrome profile actually is on macOS

A profile is a directory. On macOS they live under ~/Library/Application Support/Google/Chrome/. The first one created is called Default, and every profile added after that becomes Profile 1, Profile 2, and so on. Inside each directory sits an extensionless file named Bookmarks, which is the bookmark set as plain JSON, along with separate history, cookie, password, and extension stores.

The display name shown in the Chrome interface has no connection to the folder name. Renaming a profile to "Work" leaves the folder as Profile 1. The mapping between the two is held in a file called Local State in the parent directory, under a key named profile.info_cache, which lists folder names alongside display names and signed-in email addresses.

To find out which folder the current window is reading from, type chrome://version in the address bar and look at the Profile Path line. The last segment of that path is the folder name.

If that folder name is not the one normally used, the bookmarks were never deleted. They are sitting in another directory, untouched.

This single check resolves a large share of cases, and it takes about five seconds. Everything below assumes it has already been done and the profile path is the expected one.

Reading Local State to find the right folder

When several profiles exist and none of the folder names mean anything, Local State settles it. It is a JSON file in the Chrome support directory, one level above the profile folders, and it holds a section called profile.info_cache. That section lists every persistent profile with its folder name as the key, and inside each entry sits the display name and, for signed-in profiles, the account email address.

Opening it in a text editor works, though it is written as a single long line. Piping it through a formatter makes it readable, and a read-only command avoids any risk of altering it while Chrome is closed.

python3 -m json.tool ~/Library/Application\ Support/Google/Chrome/Local\ State | grep -A3 '"name"'

The point of this step is to avoid guessing. Renaming or moving the wrong folder is the one action in this whole process that turns a recoverable situation into an unrecoverable one, and matching the email address to the folder name removes that risk. It also answers the question of how many profiles exist, which is how an accidentally created profile gets discovered.

If a folder exists on disk but does not appear in profile.info_cache, Chrome is not currently aware of it. That happens after a profile has been deleted from the interface but not yet cleaned from disk, and it means the bookmarks inside it are still readable even though Chrome no longer lists the profile. Copying the Bookmarks file out of that folder and importing it into a live profile is often the fastest recovery available.

The four ways bookmarks appear to vanish

Working through the likely causes in order is faster than jumping to recovery.

The profile itself changed

Clicking the avatar and picking another name does not swap the account inside the same window. It opens a new window belonging to a different profile, with different bookmarks, different extensions, and a different session. The avatar in the top right will show a different initial or picture. Picking the original name from the same menu brings everything back.

The window is a guest window

Guest windows are built to leave nothing behind. They load no existing bookmark set, so the bar is empty by design, and nothing added during the session survives the window being closed. If the work happened in a guest window, those bookmarks are not recoverable, and the practical response is to accept that and move on.

A sign out removed local data

Signing out of Chrome can present a prompt asking whether to delete data from this device. Accepting it detaches bookmarks and history from that profile on the local machine. On accounts managed by a workplace or a school, an administrator policy can make that deletion automatic. In this case the local copy is gone but the account copy may still exist, which is covered further down.

A new profile was created without notice

Signing in to a different Google account on a web page prompts Chrome to offer a new profile for that account. Accepting moves the session into a fresh, empty profile. It is easy to miss while concentrating on something else. Opening the Chrome support directory and counting the Profile folders will show whether more exist than expected.

Quit Chrome before doing anything else

Chrome keeps exactly one backup generation of the bookmark file. At startup it copies the current Bookmarks file to Bookmarks.bak in the same folder. That copy is overwritten at the next startup.

This is why repeated relaunching during troubleshooting is dangerous. Each launch while the bookmark set is empty replaces the good backup with an empty one. The safest first action is to quit Chrome completely, then duplicate the whole Chrome support directory somewhere else.

cp -R ~/Library/Application\ Support/Google/Chrome ~/Desktop/Chrome-backup

The same thing works from Finder. Use Go to Folder, paste the path, and copy the Chrome directory to the desktop. It can run to several gigabytes because extensions and caches are included, but keeping the whole thing until the cause is confirmed means every later step is reversible.

Restoring from Bookmarks.bak

When the profile path is correct and the set is still empty, the backup generation is the next place to look. The sequence is short.

• Quit Chrome fully. Closing windows is not enough.
• Open ~/Library/Application Support/Google/Chrome/ and enter the folder named in chrome://version.
• Rename Bookmarks to Bookmarks.old.
• Rename Bookmarks.bak to Bookmarks.
• Launch Chrome and check that profile.

Nothing is deleted at any step, so the move is reversible. If the result is wrong, renaming Bookmarks.old back to Bookmarks returns the previous state. If Bookmarks.bak is missing or itself empty, this route is closed, which is the usual outcome after Chrome has been relaunched several times.

Once a good set is back on screen, export it immediately. The bookmark manager has an export option that writes an HTML file readable by any browser and by any other profile. That file is also the simplest way to move a bookmark set between profiles later.

When the profile opens as though it were new

A different failure looks similar but has a different cause. The profile path in chrome://version is correct, the folder is full of files, and Chrome still opens as if the profile had just been created. Bookmarks are empty, the theme is back to default, and Chrome may show a message saying the profile could not be opened correctly.

This is usually a damaged Preferences file rather than a missing bookmark file. Preferences is JSON, and if it is truncated by a crash, a full disk, or an interrupted shutdown, Chrome falls back to defaults rather than refusing to start. The bookmark file next to it is typically untouched.

The recovery path is the same shape as before and just as reversible. Quit Chrome, rename Preferences to Preferences.old, and launch again. Chrome writes a fresh Preferences and rereads Bookmarks from disk, which often brings the whole set back with only display settings lost. If it does not help, renaming the file back restores the previous state exactly.

A related case is a full startup disk. Chrome writes the bookmark file by replacing it, and a write that fails partway through can leave a short or empty file behind. Checking available disk space before repeating any repair is worth the ten seconds, because a repair performed on a full disk can fail in the same way and consume the one backup generation in the process.

Checking the account side

If sync was ever switched on for the profile, bookmarks also exist on the Google account rather than only on the machine. Signing back in with the same account and enabling sync usually brings them down after a short delay. It is worth confirming in settings that bookmarks are among the selected data types, since sync can be limited to a subset.

The complication here is the sync passphrase. Setting a custom passphrase encrypts the synced data, and signing in again is not enough to read it. Without that passphrase the only remaining option is resetting sync, which clears the copy held on the account. That button is not a recovery step, and it is worth pausing before pressing it.

Google's data export service can also produce a copy of Chrome data tied to the account. It requires identity verification and a wait while the archive is prepared, so it is not a first response, but it remains available after a machine has been wiped.

Restoring from Time Machine

Time Machine can return a single Bookmarks file from a point before the loss. Apple documents hourly snapshots for the past 24 hours, daily snapshots for the past month, and weekly snapshots for earlier periods, so a same-day loss can usually be rolled back by the hour.

Three details matter. Chrome must be quit first, or the running process will write its in-memory state back over whatever is restored. The restore should target the single file rather than the whole profile folder, because folder-level restores also roll back extensions and saved passwords. And the current Bookmarks file should be copied aside first, so that picking the wrong snapshot is not a one-way move.

Keeping a copy that does not depend on Chrome

Every recovery route above depends on something Chrome or Google controls. One backup generation, one sync passphrase, one account. A copy that sits outside all of that is cheap to make and removes the whole problem class.

The bookmark manager exports the full set as a single HTML file. That format is portable across browsers and across profiles, and it is small enough that keeping several dated copies costs nothing. Exporting after any large reorganisation, and once a month otherwise, is enough for most people.

For anyone comfortable in the terminal, copying the raw file achieves the same thing with one command and can be scheduled.

cp ~/Library/Application\ Support/Google/Chrome/Default/Bookmarks ~/Documents/bookmarks-$(date +%Y%m%d).json

The path segment Default needs replacing with the folder name found earlier for the profile that matters. A copy taken this way is the raw JSON, which Chrome cannot import directly through the interface, so pairing it with an occasional HTML export covers both restore methods.

Neither approach protects against the same file being wrong in the copy. Checking that an export opens and shows the expected folders, once, is what separates a backup from a file that is assumed to be a backup.

What to change first

Restoring the file fixes today. It does not change the condition that produced it, which is that every profile window looks identical. Same icon, same shape, same position, with only a small avatar to tell them apart.

Two directions help. Inside Chrome, give each profile a distinct theme colour, keep display names short, and turn on the profile picker at startup so the choice is deliberate rather than accidental. Beyond Chrome, the alternative is to stop switching at all by giving each web app and each account its own persistent window and session, which is what Workspaces and the wider feature set describe. If the comparison is against other tools in that category, the Wavebox comparison lays out the differences in plain facts.

Start with chrome://version, quit Chrome before touching any file, and export the bookmark set to HTML the moment it is back. That export is what turns the next occurrence into a two minute problem. If switching profiles several times a day is the underlying pattern, the thing worth changing is the window model, and SpaceDeck exists for that case.