Recover Bookmarks and Passwords From a Broken Chrome Profile
Short answer
Close Chrome completely and copy the whole User Data folder somewhere safe before changing anything — every step below destroys data if done in the wrong order. Bookmarks live in a file named Bookmarks with a Bookmarks.bak beside it, and renaming the backup over the original restores the last good copy. Passwords cannot be moved between machines by copying files, because they are encrypted to the original user account.
On this page
Chrome opens to an empty bookmarks bar. Or it will not open at all. Or it starts as though you have never used it, with no history, no extensions and no saved passwords.
A profile is a folder of files, and like any folder of files it can be damaged by an unexpected shutdown, a failing disk, a sync conflict or an interrupted update. Most of what is in it is recoverable, and the recovery is not difficult.
What makes this go badly is doing things in the wrong order. Deleting a profile to “start fresh” before copying it removes the only evidence of what you had.
Before anything else
Close Chrome completely and copy the entire User Data folder to your Desktop or an external drive. Not move. Copy. Every subsequent step becomes reversible once you have that copy, and nothing below is safe without it.
Closing Chrome means every window, plus any background process. Check the system tray on Windows for a Chrome icon and choose Exit. Chrome writes profile files on shutdown, and copying them while it is running gives you a half-written set.
The folder:
- Windows:
C:\Users\[you]\AppData\Local\Google\Chrome\User Data - macOS:
~/Library/Application Support/Google/Chrome - Linux:
~/.config/google-chrome
AppData and Library are hidden. Paste the path into the File Explorer address bar on Windows, or use Go → Go to Folder in Finder on macOS.
Inside it you will find Default (your first profile), then Profile 1,
Profile 2 and so on if you have more. Also Local State, which maps those
folder names to the profile names you see in Chrome.
Check sync before touching files
If sync was on, this may already be solved. Sign into Chrome on a second device — a phone counts — and look.
- Bookmarks are there on the other device. Sign in on the broken machine and they will come back. Stop here.
- Bookmarks are missing there too. The loss has already synced. Local file recovery is the route, and it is why the copy you just made matters.
The same logic applies to passwords at chrome://password-manager on the other
device, and to history. Sync propagates deletions as readily as additions, which
is the thing people do not expect.
Recovering bookmarks
Chrome keeps two files in each profile folder:
Bookmarks— the live file, no extension.Bookmarks.bak— a copy written at startup, reflecting the state at the end of your previous session.
That backup is one session old, which is exactly the right vintage when bookmarks vanished during a session.
With Chrome fully closed:
- Rename
BookmarkstoBookmarks.old. Rename, do not delete — if the backup turns out to be worse, this is the only way back. - Rename
Bookmarks.baktoBookmarks. - Start Chrome.
If the bar is populated, export immediately: ⋮ → Bookmarks and lists → Bookmark manager → ⋮ → Export bookmarks. You get an HTML file that imports into any browser, and it is the copy that does not depend on anything working.
Both files are JSON and readable in a text editor. If Bookmarks is zero bytes
or opens as gibberish, it is damaged and the backup is your answer. If the
backup is also empty, there is no further local copy, and
getting back an earlier version of a file
covers whether File History or Time Machine has one.
Recovering passwords, and what is not possible
Be clear about the limit here, because a lot of advice on this is wrong.
Saved passwords live in a file named Login Data, encrypted with a key bound to
your operating system user account — DPAPI on Windows, Keychain on macOS. Copy
that file to another computer, or to a different user account on the same
computer, and it decrypts to nothing. There is no password you can type to
unlock it.
So:
- Copying
Login Datato a new machine does not work. Any guide suggesting it either omits this or is wrong. - It does work within the same Windows user account, which is the one case that matters: restoring the file into a rebuilt profile on the same machine.
- Tools claiming to extract Chrome passwords from an arbitrary profile file are a category to stay away from entirely. The ones that function are the same tools malware uses, and several distributed under that description are malware.
If Chrome still opens at all, export properly while you can:
chrome://password-manager → Settings → Export passwords.
That export is a plain-text CSV. Anything with read access to your disk can read every password in it. Export it, import it into wherever it is going, then delete it and empty the recycle bin. Do not leave it in Downloads and do not email it to yourself.
Rebuilding the profile
When the profile is beyond repair but the files are intact, rebuild around them.
With Chrome fully closed, rename the User Data folder to User Data.old.
Start Chrome, and it builds a clean profile directory from scratch.
Rename rather than delete. This is the step where people lose everything permanently. The old folder is the only remaining copy of anything that was never synced, and renaming costs nothing while keeping every option open.
Then restore selectively into the new Default folder, closing Chrome between
each attempt:
| File | Holds | Restores across machines? |
|---|---|---|
Bookmarks |
All bookmarks | Yes |
History |
Browsing history | Yes |
Web Data |
Autofill, addresses | Yes |
Login Data |
Saved passwords | Same user account only |
Preferences |
Settings | Yes, but it is a common corruption source |
Copy one file at a time and start Chrome after each. If the problem returns after a particular file, that file was the damaged one. Restoring everything in one go reproduces the original problem and tells you nothing about its cause.
Preferences is the file to be most suspicious of. It is a large JSON document
touched constantly, and it is a frequent corruption candidate. Leaving it behind
costs you your settings and often resolves the fault.
What usually caused it
Worth knowing so it does not recur:
- Forced shutdowns while Chrome was running. Power loss, a held power button, a battery that cut out. Chrome writes these files on exit, and an interrupted write produces exactly this.
- A failing disk. If other files are also misbehaving, check the drive’s health before rebuilding anything on it.
- Cleanup utilities. Tools that “optimise” browser databases while Chrome is running have no safe way to do that.
- Profile folders in synced storage. A
User Datafolder inside OneDrive or Dropbox gets corrupted reliably, because two processes write the same SQLite files at once. If yours has ended up there, how OneDrive redirects your user folders explains how it happens and how to undo it.
What to expect
Bookmarks recover from Bookmarks.bak in most cases, and the five minutes of
renaming is the whole job.
Passwords recover when sync had them or when the profile is being rebuilt on the same user account. Across machines, the encryption is the hard boundary and there is no technique that crosses it — which is an argument for having sync on, or a separate password manager, before you need either.
History and autofill come back with their files more often than not. Extensions need reinstalling, and that is usually a reasonable moment to not reinstall all of them.
If Bookmarks and Bookmarks.bak are both empty and sync was off, the data is
gone. A file-recovery tool on the drive occasionally turns up an older copy, and
it is a long shot rather than a plan.