Built-in browser password managers are safe enough for most people and far safer than reusing passwords, provided the device is locked and the store is protected. They encrypt saved logins, generate strong ones, sync with end-to-end or account-level encryption, and refuse to fill on lookalike domains. A dedicated manager is better if you use several browsers, share credentials or want audited apps across every platform.
The question behind the question
When people ask whether the browser's password manager is safe, they are usually comparing it with one of two alternatives: a dedicated manager such as Bitwarden, 1Password or KeePassXC, or the status quo of remembering a few passwords and reusing them. Against the second, every manager wins decisively, for the reasons set out in password security: reuse is how most accounts are taken over, and a manager is the only practical way to have a unique, long password for each of a few hundred sites. So the real question is the first one, and it has a more nuanced answer.
How each browser protects what it stores
| Browser | At rest on the device | In sync | Extra protection |
|---|---|---|---|
| Chrome (Google Password Manager) | Encrypted with an OS-held key: DPAPI plus App-Bound Encryption on Windows, Keychain on macOS, keyring on Linux | Encrypted with Google's keys by default; optional on-device encryption makes it end-to-end under your Google password or screen lock | Password Checkup for breached and reused passwords; option to require the OS password or biometric before filling |
| Firefox | logins.json encrypted with a key in key4.db; without a primary password that key is readable by any process running as you | Firefox Sync is end-to-end encrypted with a key derived from your account password | Primary Password; Firefox Monitor breach alerts; OS authentication before revealing |
| Safari (iCloud Keychain / Passwords app) | Keychain, protected by the device passcode and Secure Enclave on Apple hardware | End-to-end encrypted; Apple cannot read it | Passwords app on iOS 18 and macOS Sequoia; passkeys; verification codes; shared groups; compromised-password alerts |
| Edge | Encrypted with the OS-held key, as Chrome | Encrypted under your Microsoft account; recoverable by the account | Password Monitor; option to require the device password before autofill |
Two rows need attention. Firefox's store, by default, is protected only by your operating-system login; set a Primary Password under Settings > Privacy & Security > Logins and Passwords and the store is encrypted under something an attacker with your files does not have. Chrome's sync encryption is, by default, under keys Google holds, which means a compromise of your Google account exposes the passwords; switching on on-device encryption at passwords.google.com changes that to end-to-end, at the cost of Google no longer being able to help you recover them.
Where built-in managers are weak
The honest weaknesses are not in the cryptography. They are in what happens while you are logged in.
- The running session. When you are logged in to your computer and the browser is open, its password store is, by design, decryptable by the browser, and therefore by anything running with your privileges. Infostealer malware exists almost entirely to exploit this: it copies the browser's login database and the key needed to open it, and it has been one of the most common malware families for years. Chrome's App-Bound Encryption, added in 2024, ties the key to the browser's own process on Windows to raise the bar; it is a mitigation, not a wall. Dedicated managers that lock after a timeout and require the master password again are better here, though a compromised machine ultimately defeats every manager.
- Anyone at the keyboard. The saved-passwords page in Chrome, Edge and Safari requires the operating-system password or a biometric before revealing a password in plain text. Firefox without a primary password does not. Autofill, however, works without any prompt unless you enable the option to require authentication before filling. On a shared or unlocked machine that is an exposure.
- Portability. A password saved in Safari is not available in Firefox on a Windows laptop. Every vendor has an export, and some have bridging extensions, but a person who uses two browsers or two ecosystems ends up with two half-stores.
- Sharing. Safari now offers shared groups within Family Sharing; the others largely do not. Households and small teams that share logins are the clearest case for a dedicated manager with proper sharing and audit.
- Recovery. A Google or Microsoft account can usually recover your store, which is a convenience and a risk: whoever can pass account recovery can get your passwords. End-to-end options remove that, and then loss of the key is loss of the data.
The phishing defence you get for free
All four browsers save a login against the exact site it was used on and offer to fill it only there. Arrive at account-example.com instead of example.com and the manager stays silent, because it has nothing saved for that host. This is the single most effective anti-phishing behaviour most people have, and it works because the manager compares the origin rather than the appearance. A human sees a familiar logo; the manager sees a string mismatch. Which is why the right response when a manager does not offer to fill on a site you think you know is to stop and read the address, using the checks in how to spot phishing, rather than to copy and paste the password by hand. Our phishing URL checker reports lookalikes as lookalike of a well-known brand domain; your password manager has been doing the same check silently for years.
The stronger version of this is a passkey. Passkeys, built on the FIDO2 and WebAuthn standards, replace the password with a key pair bound to the site's origin; there is no secret to type and therefore nothing for a fake page to capture. All four browsers store and sync passkeys through the same managers described above, and support is now common on large sites. Where a site offers one, take it; the comparison with other second factors is in two-factor authentication.
Built-in or dedicated: a decision rule
- Use one browser on devices from one vendor, and do not share passwords? The built-in manager is the right choice. Lock the device, set a Firefox primary password if that is your browser, turn on Chrome's on-device encryption if you want end-to-end sync, and enable the require-authentication-before-filling option if others use the machine.
- Use two or more browsers, or Windows plus an iPhone, or Linux? A dedicated manager with extensions for every browser and apps for every platform removes the split store.
- Share logins with a partner, family or team? Dedicated manager with shared vaults and access control.
- Want secure notes, document storage, TOTP codes, emergency access or an audit trail? Dedicated manager.
- Refuse to trust any cloud with the vault? KeePassXC or an equivalent local, open-source manager, with the file synced however you choose. More work; complete control.
Among dedicated managers, prefer one that publishes a security architecture document, has undergone independent audits, and whose client code can be inspected. Zero-knowledge design, where the vendor's servers hold only ciphertext and the key is derived from a master password that never leaves your device, is the property to look for; it is what makes a vendor breach survivable, and it is why the strength of your master password matters more than anything else about the setup.
Whatever you choose, do these
Turn on the manager's breach and reuse checking, and act on it: Chrome's Password Checkup, Firefox Monitor, Safari's compromised-password alerts and Edge's Password Monitor all compare your saved passwords against known leaks. If you want to check a single password without saving it anywhere, our password checker uses the same k-anonymity method, sending only a prefix of the hash. Let the manager generate every new password; the strength of a random 20-character string is not something a human competes with. Add a second factor, ideally a passkey or hardware key, on the account that protects the manager itself. And export a copy of the store to an encrypted file every few months, so that losing the account or the device is an inconvenience rather than a loss.
Password storage is one part of the browser's job; the settings that protect the rest of it are in browser security settings and the wider picture in the browser security hub.