What is actually in a browser profile, and how to back it up properly

A browser profile is not a settings file. It is cookies for every site you are logged into, localStorage and IndexedDB for every app that stores state client side, saved passwords, and increasingly, passkeys that have no password fallback. Treat the directory like a bookmark export and you will eventually lose an account you cannot get back into.

What is inside the directory

Chromium's user-data directory holds, among a lot of cache you do not need: a SQLite database of cookies, the Local Storage and IndexedDB leveldb stores, Login Data (saved passwords, encrypted), Web Data (autofill), and session restore state. Cache, GPUCache and code cache are large and regenerate on their own, so a real backup should exclude them, not copy them.

Passkeys are the newest and least forgiving entry on that list. A passkey is bound to an authenticator, and that credential lives only where it was created. There is no "reset password" flow for a passkey the way there is for a password. If the profile holding it is gone, so is your ability to sign in, unless the site also lets you enrol a second authenticator, and many still do not.

Why copying the raw folder between machines fails

Three separate things break this, and they break silently rather than with a clear error:

File locking. Chromium locks its SQLite databases and leveldb stores while running. Copying a live profile, or one that was not shut down cleanly, can grab a database mid write and hand you a corrupted cookie or storage file on the other end.

OS-bound credential encryption. Saved passwords in Login Data are encrypted with a key tied to the operating system's credential store, DPAPI on Windows, Keychain on macOS. Move the raw file to a different machine and the encrypted blobs are unreadable there. This is by design, not a bug you can patch around.

Absolute paths. Some profile state, extension state in particular, references the profile's own filesystem path. A profile created at C:\Users\alice\profile-01 and dropped into /home/bob/profile-01 on another OS will have entries pointing at a path that no longer exists.

What a portable export should contain

A format built for moving between machines needs to solve all three problems: a clean snapshot taken while the browser is closed (no lock contention), credentials re-wrapped in a form that does not depend on the source OS's key store, and paths that are relative to the archive rather than baked in absolute. It should include the cookie and storage databases, saved logins, and the passkey store, and exclude Cache and GPUCache, which only make the archive bigger without making it more useful.

AntiBrow's profile export follows this shape: each profile can be exported to a portable archive carrying the fingerprint, cookies, storage and passkeys, so opening it on a different machine restores the same identity rather than a folder of unreadable state. Cloud sync, where the same archive is kept on AntiBrow's servers instead of only a local file, is opt-in per profile, not automatic.

Backup cadence

A profile that only matters for one session does not need a backup plan. A profile behind a client account, an ad account, or anything with a passkey enrolled is a different case: back it up after anything that changes its login state, a password reset, a new passkey enrolment, a 2FA re-pairing, not on a fixed calendar that might miss the change entirely. If you only keep one archive, keep the newest one; an old archive with a since-rotated password is close to useless and might still contain the old credential.

Where you do not need any of this

If the account behind the profile has no passkey, does not care about session continuity, and can be logged into again from scratch in a minute, a full profile backup is more process than the risk deserves. Bookmark the login page and move on. Building a profile export pipeline is worth it once losing the login costs more than an hour of your time, not before.

Treat the archive as a credential

A portable profile file is not an inert backup. It contains live session cookies and, where enrolled, working passkeys, which means anyone holding the file can act as the logged-in account, no password prompt required. Store it the way you would store an SSH key or an API token: encrypted at rest, not emailed around, not left in a shared folder. /security covers how AntiBrow handles this on its own storage and sync path.

Check it yourself

Export one profile, delete the local copy, and re-import the archive on a second machine. If the site still recognizes the passkey and the saved session without a fresh login, the export did its job. If the passkey prompts you to enrol again, something in the chain, capture, storage or import, dropped it, and that is worth finding before it happens with an account you cannot recreate.

Security page or passkey automation.