Understanding browser-local password vaults
Encrypted in IndexedDB, never on a server.
Why a browser-only vault is a niche but defensible product, the threat model it actually addresses, and where it stops being enough.
The threat model.
A browser-local password vault stores encrypted entries in the browser's IndexedDB. The encryption key is derived from a master password the user types; nothing leaves the device. The threats it addresses: someone shoulder-surfing your passwords list, a casual snoop using your unlocked machine, a backup of your data ending up in the wrong cloud folder. The threats it doesn't address: malware on your machine that can read browser storage, a phishing page that captures the master password, someone with physical access willing to wait for you to unlock the vault.
Why not LastPass / 1Password / Bitwarden.
The mainstream password managers sync across devices, share with family, handle 2FA codes, scan for breaches. A browser-local vault does none of that. It's right for users who specifically don't want cloud sync (privacy maximalists, regulated environments, situations where you can't install software). It's wrong as a general-purpose password manager — the lack of sync is a feature in a narrow case, a bug in the broad case.
The crypto baseline.
Same shape as any password-encrypted store. PBKDF2 (600,000+ iterations) or Argon2id derives a key from the master password. AES-GCM encrypts each entry with a fresh IV. Auth tag verifies on decrypt. The whole vault is one IndexedDB record (or a few). Compromise of the master password breaks everything; protect it accordingly. The browser Web Crypto API provides everything needed natively.
A worked workflow.
User opens the vault, types master password. The vault derives the key (takes ~1 second due to PBKDF2 iterations — by design, slow for brute force). Decrypts the index. User searches "github", finds the entry, clicks "copy password" — the password lives in the clipboard for 30 seconds, then is replaced. User adds a new entry: encrypts with the derived key, persists to IndexedDB. Lock the vault: clear the derived key from memory. The whole loop is local; nothing crosses the network.
Local-only loop
master pw → KDF → AES-GCM → IndexedDB
Every step is in-tab; no network.
unlock → derive key → decrypt index → read entry
= No data leaves the browser
Backup is the user's problem.
IndexedDB is per-browser-profile. Reinstall the browser, lose the vault. Use a different browser, the vault doesn't follow. Modern browsers do sync profiles via the user's Google/Apple/Microsoft account; that backup is third-party-hosted, which the threat model explicitly tries to avoid. The honest answer: export the encrypted blob periodically, keep it in a location you trust (a USB drive, an encrypted backup). The vault is private but not redundant.
The passkey transition.
Passwords are gradually being replaced by passkeys (FIDO2 / WebAuthn) — public- key credentials stored on the device, no shared secret on the server. Apple, Google, and Microsoft are pushing passkeys hard; major sites accept them. A password vault is therefore a transitional tool: most of its contents will become passkeys over the next five years, and the OS-level credential store will replace the vault. The browser-local vault is most useful right now, less so each year.