"Isn't it risky to put all my passwords in one app?" It's the most common objection to password managers — and answering it requires understanding what actually happens behind the scenes. Once you see the mechanism, the objection mostly dissolves.
The vault: an encrypted container, not a list
Your passwords aren't stored as a plain list anywhere — not on your device, not on the company's servers. They live inside a "vault": a single blob of data that's been encrypted using strong cryptography (typically AES-256, the same standard used to protect classified government information). Without the right key, that blob is computationally meaningless noise.
Your master password generates the key — and only you have it
The key that unlocks your vault is derived directly from your master password using a function designed to be slow and resistant to guessing (commonly PBKDF2, Argon2, or scrypt, run through hundreds of thousands of iterations). Critically, this derivation happens on your own device — your master password is never sent anywhere, ever, in any form.
This means the password manager company never knows your master password. They store your encrypted vault, but they have no way to decrypt it. This is called zero-knowledge architecture, and it's the core design principle behind every reputable password manager.
Why this matters if the company gets breached
Even major password manager companies have suffered breaches of their servers. Sounds alarming — but because of zero-knowledge architecture, what attackers obtain is encrypted vault data, not usable passwords. Without your master password (which was never transmitted or stored anywhere accessible), that data is useless to them. The practical risk from a server-side breach is limited to attempting to crack the encryption directly, which — with a sufficiently strong master password — is computationally infeasible.
This is precisely why your master password needs to be strong: it's the only thing standing between an attacker with your encrypted vault and your actual passwords.
How autofill actually works
When you visit a login page, the browser extension recognizes the site and asks the locally-decrypted vault (held in memory only while you're logged into the manager) for matching credentials. The decrypted data never leaves your device — it's filled directly into the form fields by the extension running in your browser. This is also a security feature: legitimate autofill only triggers on the exact domain a credential was saved for, which is part of why password managers actually help detect phishing sites (a fake lookalike domain won't trigger autofill, which should make you suspicious).
Syncing across devices
When you add a password on your phone and see it appear on your laptop, what's actually synced is the encrypted vault blob — sent over an encrypted connection to the company's servers, then downloaded and decrypted locally on your other device using the same master-password-derived key. The plaintext password itself never travels across the network or sits decrypted on any server.
The generator function
Built-in password generators in these tools use the same kind of cryptographically secure random number generation discussed throughout this site — typically your operating system's CSPRNG (cryptographically secure pseudo-random number generator). There's no meaningful security difference between a password generated inside your password manager versus a standalone tool like ours; both draw from the same category of secure randomness.
The bottom line
A password manager doesn't eliminate risk — it concentrates it into one well-defended point (your master password) instead of spreading it across dozens of poorly-defended points (every site where you reused a password). Given the choice between trusting one rigorously encrypted, zero-knowledge vault, or trusting that you'll never reuse a password across 80+ accounts, the math favors the vault.