Most password managers are databases. You put secrets in, they encrypt the file, and they sync it somewhere. The security of the whole thing rests on that encrypted file staying encrypted.
A deterministic password manager works differently. It stores nothing. You give it a seed, a site, and a username, and it derives a password from those three inputs. Feed it the same inputs tomorrow and you get the same password. There is no vault to steal, because there is no vault.
If you already hold bitcoin in self-custody, the idea will look familiar: it is the same trick as a BIP39 seed deriving an unlimited number of keys. That similarity is exactly why it appeals to people who have already made peace with backing up a seed phrase.
It is also why it is worth being careful about. The tradeoff is real, and most write-ups skip it.
How the derivation works
The mechanism is a keyed hash. In outline:
password = KDF(master_seed, site + username + nonce)
- master_seed - one high-entropy secret. In BIP39-based implementations this is the familiar 12 or 24 words.
- site + username - the context, so
github.com/aliceandgithub.com/bobproduce different passwords from the same seed. - nonce - a counter, starting at 0. It exists so you can rotate.
- KDF - a key derivation function, which turns those inputs into a fixed-length output that is then encoded into whatever character set the site demands.
Because a hash is deterministic, the same inputs always produce the same output. Because it is one-way, someone holding the output cannot work backwards to the seed. Nothing has to be saved between sessions, the manager recomputes the password each time.
The KDF is not a detail, and it is the part to check in any implementation. A plain hash is fast, and fast is what an attacker wants: anyone who obtains one derived password, from a site that stored it badly or a page that phished it, can grind candidate master secrets offline, testing each guess by deriving the password for a site they already know. A real twelve-word seed is far out of reach of that. A human-chosen master password is not, which is why serious implementations use a deliberately slow function, PBKDF2 with a high iteration count, scrypt or Argon2, rather than a bare SHA-256.
The result is a tool you can run entirely offline, from a single HTML file, with no account, no sync and no server.
What this genuinely buys you
No vault to breach. The recurring nightmare of the password manager industry is the encrypted vault getting exfiltrated and then attacked offline at leisure. LastPass disclosed in December 2022 that an attacker had copied a backup of customer vault data, which is exactly that shape. A deterministic manager has no such file.
No sync, no trust. No provider to depend on, no subscription to lapse, no service to shut down and take your logins with it.
One backup covers everything. If you have already built the discipline for storing a seed phrase, you are reusing it rather than adding a second, different backup problem.
Auditable in an afternoon. These tools are small. The whole logic fits in a page of code, which is a meaningful property for something holding every credential you own.
What it costs you
This is the section that decides whether the tool is right for you.
Your seed becomes a single point of total failure. Not "some accounts" - every account, at once, silently. With a vault, an attacker needs the file and the master password. Here, the seed alone reconstructs everything, and you get no signal that it happened.
Rotation is bookkeeping you now own. Change a password and you must remember that
github.com/alice is on nonce 3 while everything else is on 0. That state has to live
somewhere. The moment you save it, you have reintroduced the file you were trying to
avoid, and if you lose it, you cannot regenerate passwords you are already using.
You cannot import. Every existing password has to be changed to a derived one, one account at a time. Anything you cannot change (a work account under someone else's policy, a bank that mails you a PIN) has to be kept somewhere else. Most people end up running two systems.
Site password rules fight the design. Maximum lengths, mandatory special characters, banned characters, and rules that change over time all force the encoder into site-specific handling. That handling is state too.
Compromised means re-keying everything. If the seed leaks, there is no "change the master password" step. Every derived password is compromised and every account has to be changed by hand.
Shared credentials do not work. There is no way to share one login with a partner or a team without sharing the seed, which shares everything.
Where that leaves it
Deterministic derivation is a good fit for a specific person: someone comfortable with seed-phrase discipline, with a manageable number of accounts, who rarely rotates, who does not share credentials, and who wants no dependency on any provider.
It is a poor fit for most people, and the reason is not cryptographic. A well-run encrypted vault with a strong master password and a hardware second factor gives ordinary users better outcomes, because it survives the mistakes people actually make: forgetting where the nonce list went, needing to share a login, changing one password in a hurry.
Neither choice is careless. They fail differently, and you should pick the failure you can live with.
Looking at an implementation
PasswordManagerWeb is a small browser-based tool of this kind, and reading it is worth more than the description above, because it is where the description stops matching the code. Checked against the repository on 20 August 2026:
- It does not use a key derivation function. The password is the first sixteen hex characters of a single unsalted SHA-256 over the key, username, site and nonce, between a fixed prefix and a fixed suffix. There is no work factor, and every password it produces carries the same recognisable shape.
- It does not use the BIP39 seed derivation. It builds the key by concatenating each word's position in the BIP39 list as decimal digits and reading the result as hexadecimal. The words are BIP39 words, the derivation is not, so no other BIP39 tool reconstructs the same key from the same backup. That backup is only usable in this tool.
- It is no longer storage-free. The README documents optional Nostr backups and an optional encrypted copy of the session data, the nonce dictionary included, kept in browser storage.
- There is no licence file, one contributor, and no independent review. The last commit was in September 2025.
None of that means the author did anything wrong, and the code being short enough to read in one sitting is exactly why it is worth reading. It does mean the tool should not be holding real credentials, and the distance between what a tool of this kind is described as doing and what its code does is the reason the checklist below exists.
Before trusting any password tool with real accounts:
- Read the derivation itself, and confirm it runs a slow, salted KDF rather than a bare hash.
- Check it has a licence, so you know what you are permitted to do with it.
- Check whether anyone independent has reviewed the derivation code.
- Run it offline, from a local copy, and confirm it makes no network requests.
- Derive a password twice, in two separate sessions, and confirm you get the same result before you change a single real account to it.
- Test recovery from your backup on a different machine, before you rely on it.
That last one is the whole ballgame. A derivation scheme you cannot reproduce from your backup is not a password manager - it is a way to lose every account you own on the same afternoon.
Browser-based tools, specifically
Anything that runs in a browser inherits the browser's threat model: extensions with page access, a compromised tab, a poisoned update to a page you loaded from the network. If you use one of these tools, save the page locally, open it from the filesystem, and check it works with networking off. A tool that is only safe offline should actually be run offline.
Related: wallet generation and entropy covers the same question, where a secret's randomness comes from and how you know it is real, for bitcoin keys rather than passwords.
Correction, 20 August 2026. This post originally presented PasswordManagerWeb as a readable implementation of the derivation described above. Reading the code, it is not one: it hashes its inputs with a single unsalted SHA-256 rather than with a key derivation function, and it maps the seed phrase to a key by concatenating BIP39 word indices instead of using the BIP39 derivation, so the backup cannot be restored with any other BIP39 tool. The post also said of tools of this kind that there is no vault to steal; that project has since added optional Nostr backups and optional encrypted browser storage, so it no longer describes this one. The section has been rewritten and the tool is no longer offered as a reference implementation.