Where are browser passwords stored?
2026-06-21 · 4 min
Saved passwords are rarely in one obvious place, and they are never in plaintext. Each browser keeps the username and the URL recoverable on disk, but wraps the password itself in OS-level or profile-level crypto. Knowing which file holds the credential — and which key unlocks it — is the difference between a five-minute pull and a dead end.
The short answer
| Browser | File(s) | Protection |
|---|---|---|
| Chrome / Edge / Brave / Chromium | Login Data (SQLite, logins.password_value) | os_crypt key — Windows DPAPI, macOS Safe Storage, Linux keyring |
| Firefox | logins.json + key4.db (legacy key3.db) | NSS-encrypted; key protected by the primary password |
| Safari | macOS login Keychain / iCloud Keychain (not a Safari file) | Keychain encryption, unlocked by the login password |
The pattern: Chromium and Firefox store credentials inside the profile, Safari does not. That single fact changes your whole acquisition plan.
Chromium family (Chrome, Edge, Brave, Vivaldi, Opera)
Saved logins live in the Login Data SQLite database in the profile root:
Windows C:\Users\<user>\AppData\Local\Google\Chrome\User Data\<profile>\Login Data
macOS /Users/<user>/Library/Application Support/Google/Chrome/<profile>/Login Data
Linux /home/<user>/.config/google-chrome/<profile>/Login Data
For Edge, swap the vendor path (…\Microsoft\Edge\User Data\…); the schema
is identical.
Inside, the logins table holds one row per saved credential. The URL
(origin_url, action_url) and the username (username_value) are in
plaintext. The password sits in password_value as ciphertext, encrypted
with the browser's os_crypt key:
- Windows — the key is wrapped with DPAPI, tied to the user account.
- macOS — the key ("Chrome Safe Storage") lives in the login Keychain.
- Linux — the key comes from the desktop keyring (GNOME Keyring / kwallet), or a hardcoded fallback when no keyring is present.
So Login Data alone is not enough on Windows or macOS — you also need the
DPAPI master key or the Keychain entry that protects os_crypt. See
Chrome Login Data forensics for the
full extraction path.
Firefox
Firefox splits the credential and its key across two files, both in the
profile root (xxxxxxxx.default-release):
Windows C:\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\
macOS /Users/<user>/Library/Application Support/Firefox/Profiles/<profile>/
Linux /home/<user>/.mozilla/firefox/<profile>/
logins.json— usernames and passwords, both stored as NSS-encrypted blobs (the URL stays readable).key4.db— the master key that NSS uses to decrypt those blobs. Older profiles usekey3.dbinstead.
The key in key4.db is itself protected by the primary password
(formerly "master password"). In practice this is often blank, which means
logins.json + key4.db is enough to recover everything without any OS
secret. When a primary password is set, you need it (or to crack it) before
NSS will release the key. The mechanics are in
Firefox password decryption with NSS.
Safari
Safari is the exception: it stores no passwords in a browser file.
There is nothing useful in ~/Library/Safari for credential recovery.
Instead, Safari hands saved logins to the macOS login Keychain (and, if
enabled, iCloud Keychain):
/Users/<user>/Library/Keychains/login.keychain-db
The Keychain is encrypted and unlocked by the user's login password. That is why recovering Safari passwords means parsing the Keychain with the account password — not pulling a SQLite file. If you only image the Safari profile folder, you will not find a single credential.
What this means for acquisition
- Chromium — grab
Login Dataand theos_cryptsecret (DPAPI master key on Windows, the Keychain "Safe Storage" entry on macOS). On Linux, capture the keyring. - Firefox — grab both
logins.jsonandkey4.db(orkey3.db). Note whether a primary password is set. - Safari — grab
login.keychain-dband obtain the login password; the Safari folder itself is not relevant here.
For where every other artifact lives, see where browsers store their artifacts.
Decrypting in the browser
BrowserForensics decrypts Chromium Login Data and Firefox logins.json
(via key4.db/key3.db) entirely client-side — nothing leaves your
machine. Safari Keychain parsing is out of scope, because the credentials
are not part of the browser profile. You can
decrypt Firefox passwords in your browser
directly.