How to choose a password manager, without trusting a ranking
The criteria that separate a password manager you can trust from one you merely like, when the browser's store is enough, and how to set one up so you can't lose it all.
Searching for the best password manager gets you a ranking, and the ranking was built by people who get paid when you click through. There is no best one. There is a short list of properties a password manager must have, a shorter list of trade-offs you have to choose between, and a setup procedure that matters more than the brand. That is what this post gives you.
Why a manager beats memory and the browser
A human can hold perhaps a dozen distinct passwords and will reuse one of them everywhere else. Reuse is what credential stuffing depends on: one site leaks its database, the attacker tries the same email and password against every other site, and it works. A password manager breaks that chain by making every password unique, long and random, because you never have to remember any of them.
The manager also does something your memory can't: it checks the domain before it fills. If you land on a lookalike login page, the extension has no entry for that domain and offers nothing. That is a quiet, free phishing defence, and it's the strongest argument for using one at all.
The browser's built-in store (Chrome, Safari, Firefox, Edge all have one) is genuinely fine for a lot of people. It's free, it syncs, and it checks domains too. Use it if you live inside one browser ecosystem, don't share credentials with anyone, and your account for that browser is itself protected by strong 2FA. It falls short when you need cross-platform sync, secure sharing, or storage of things that aren't web logins (SSH keys, recovery codes, card details). The browser store is only as safe as the browser account, so check that first.
What the best password manager has to have
Run any candidate through this list. A product that fails the first two is out regardless of how it scores on the rest.
Zero-knowledge encryption. The vault must be encrypted on your device with a key derived from your master password, and the vendor must never see either. Look for the phrase "end-to-end" or "zero-knowledge" and then look for the key derivation function they use (Argon2 or PBKDF2 with a high iteration count). If the vendor could reset your master password for you, they can read your vault. That is disqualifying.
Audits or open source. A published third-party security audit, with the report readable by you, or a source tree you or anyone else can inspect. Both is better. A vendor that says "military-grade encryption" and offers nothing you can read is asking for trust it hasn't earned.
A recovery story you understand. Ask: what happens if I forget the master password? With true zero-knowledge, the honest answer is that the vault is gone, unless you set up a recovery mechanism in advance (a printed recovery key, an emergency contact, a family admin). Read the recovery page before you sign up, not after.
2FA on the vault. The login to the manager itself should accept a hardware key or an authenticator app. SMS alone is not enough for the one account that holds all the others.
Passkey support. Passkeys are replacing passwords for the sites that support them, and your manager should be able to store and sync them. The passkeys post covers what a passkey actually stops. A manager that can't hold them will feel dated quickly.
Breach monitoring. The manager checks stored passwords against known leaks and tells you which to rotate. Useful, though the breach exposure tool gives the same signal.
Sharing. If you need to hand a login to a partner, a parent or a colleague, the manager should do it as an encrypted share, not by you pasting the password into a chat.
Export. You must be able to export the vault in a plain format (CSV or JSON) so you can leave. A product that makes leaving hard is a product that knows its retention depends on lock-in.
Disclosure track record. Search the vendor's name with "security incident". Every long-lived vendor will have something. What you're reading for is how they wrote it up: what was taken, what the encryption protected, what they changed. A clear write-up beats no history at all, because the second may simply mean they aren't telling you.
The trade-offs nobody can resolve for you
Cloud sync versus local-only. A cloud-synced vault means the encrypted blob sits on the vendor's servers. If the encryption is done right, that blob is useless without your master password, but it is still a target, and breaches of vault storage do happen. A local-only vault (a file on your disk, synced however you choose) removes the vendor from the picture entirely. The cost is that backup becomes your job. Lose the device and the file with no copy, and that's the vault gone. Most people are worse at backups than vendors are at encryption, which is why I lean cloud unless you already have a backup discipline.
Browser extension versus no extension. The extension is what makes autofill and domain checking work. It's also code running inside your browser with access to every page you visit, and extensions have been a real route for attackers in the past. The trade-off is convenience against attack surface. Keep the extension, but install it only from the vendor's official listing, keep it updated, and turn off any "auto-fill without a click" setting so a hidden form on a malicious page can't harvest a credential silently.
Setting it up so you can't lose everything
- Choose a passphrase, not a password, for the master. Four or five
random words, something you can type from memory and never reuse anywhere. Test it in the password strength tool, and read why strength meters lie first so you know what the score does and doesn't mean. Length is what counts here; symbols are not.
- Turn on 2FA for the vault before you add a single entry. Authenticator
app or hardware key. Store the backup codes somewhere that isn't the vault.
- Set up recovery or emergency access now. Print the recovery key if the
product issues one and put it where you keep your passport. If the product offers emergency access (a trusted person can request the vault after a waiting period), configure it. Menus move, so look for "emergency", "recovery" or "trusted contact" in the account settings.
- Migrate in stages. Import from the browser store first, then add the
accounts that matter most (email, bank, phone carrier) and rotate those passwords to generated ones immediately. Leave the long tail for later. Don't try to rotate everything in one evening; you'll stop halfway and not know which are where.
- Only then, delete from the browser store. Once the manager is filling
reliably, clear the old store so you don't have two sources of truth.
Frequently asked questions
Is a password manager safe if the company gets hacked? If the manager is zero-knowledge and your master password is a long passphrase, an attacker who steals the encrypted vault has a file they can't open in any useful amount of time. If your master password is short or reused, that same file is crackable offline at the attacker's leisure. The company's breach is survivable; a weak master password is not.
What if I forget my master password? With a properly built zero-knowledge manager, nobody can reset it for you, so the vault is lost unless you configured recovery in advance. That's the price of the vendor not being able to read your data. Set up a printed recovery key or emergency access on day one.
Should I keep 2FA codes in the same manager as the passwords? It's a trade-off. Keeping both in one vault is convenient and still far better than no 2FA, but it collapses two factors into one if the vault is ever opened. If the account matters (email, banking), keep its 2FA in a separate authenticator app or on a hardware key.
Pick one that passes the first two criteria, set the master passphrase and 2FA today, and move your email account into it before anything else. Email is the account that resets all the others, and the first hour of a hacked account goes much better when it's the one account you know is locked down.