Aditya Sharma

Is Chrome’s Password Manager Safe? What Google’s Own Pages Say

On this page, 9 sections

Chrome’s password manager encrypts what it saves and checks it against known breaches, so it is not careless. Its weak point, by Google’s own account, is malware running as you on your computer.

In a July 2024 post on its security blog, the Chrome security team said the Windows protection Chrome used for secrets, DPAPI, does not protect against malicious applications able to execute code as the logged in user. That is the case that matters for most real attacks on a home computer, and it is where a dedicated password manager tries to do better.

This post sets out what Google’s own pages say, read on 11 October 2026, where they stop, and what I would switch on if you stay with Chrome. I did not test Chrome’s storage or attack it.

What Chrome does protect

Google’s Chrome Help page on how Chrome protects your passwords makes three claims. First, when you sign in to a site, Chrome encrypts your username and password with a secret key known only to your device, then sends an obscured copy to Google, so Google does not learn them.

Second, a breach check works by encrypting your credentials first and comparing them against an encrypted list of known breached data. Third, the warning if a saved password was exposed in a breach is turned on by default.

Chrome’s password help page adds the checkup: you can check all saved passwords at once for ones exposed in a breach and for weak, easy to guess ones. It also says Chrome can ask for your fingerprint or your device’s screen lock before it fills or reveals a password, with Windows Hello on PC and your screen lock on Mac.

These are real controls. A browser manager that checks breaches and asks you to authenticate on the device is better than reusing one password everywhere.

Two pages that describe two encryption modes

Here is the part I found worth slowing down for. Google’s Account Help page on on-device encryption describes two modes. In the default one, your password is scrambled with a unique key and Google holds the key; the page says this means you trust Google to hold the key.

With on-device encryption, you take the key with you, only you can see your data, and losing the key can mean losing your passwords and passkeys.

The Chrome page’s “key known only to your device” line describes the breach check. The Account page is about how saved passwords are stored, and says that in one mode Google holds the key.

I could not tell from either page which mode a given account is in by default, and I did not check my own. So I will not claim Google cannot read your passwords. Look at your own settings and read the on-device encryption page before you rely on either claim.

Where Google’s own blog says the gap is

The Chrome security team’s post of 30 July 2024 describes how Chrome secures sensitive data: the Keychain on macOS, a system wallet such as kwallet or gnome-libsecret on Linux, and the Data Protection API (DPAPI) on Windows.

It says DPAPI protects data at rest from other users and cold boot attacks, but not from malicious applications that can run code as the logged in user, which infostealers take advantage of.

The post then introduces App-Bound Encryption in Chrome 127, which ties encrypted data to the identity of the application so another app trying to decrypt it fails. It says Chrome would migrate each type of secret, starting with cookies in Chrome 127, and that it intended to expand the protection to passwords and payment data in future releases.

I read the post as of its date. I did not verify whether passwords have since moved to App-Bound Encryption. That is the single most useful thing to check before you decide, and a Chrome release note or Google security post newer than July 2024 would answer it.

The post also says malware that runs elevated can bypass the protection, and that it works best where users cannot run downloads as Administrator.

One more limit on what I can tell you. Google’s pages describe the design in general terms. They do not publish a test of how long it takes an attacker to get past any of these protections, so I have no number to put against them, and I would distrust anyone who quotes one without a source.

What that means in practice

  • If malware runs as you, a protection tied to your login session is the thing it targets. That is Google’s description, not mine.
  • A device authentication prompt in front of autofill helps against someone at your keyboard. It is a different protection from the one in the blog post.
  • Cookies were Chrome’s first migration. A stolen session cookie can bypass a password, which is why that came first.

The third point is my reading of why the order makes sense. The post does not say it in those words.

What I would switch on if you stay with Chrome

  1. Turn on the breach warning if it is off. Chrome’s page says you will find it under Privacy and security, Security.
  2. Run the Checkup from Google Password Manager and change anything it flags as exposed or weak.
  3. Turn on the device authentication prompt before autofill: Windows Hello on PC, screen lock on Mac, per Chrome’s password help page.
  4. Read the on-device encryption page and decide which mode you want. Know that losing the key can mean losing the data.

When a dedicated manager is the better choice

If you want one vault that works across Chrome, other browsers and your phone, with your own master password, a dedicated manager is the straightforward answer. I made that argument at length in password manager vs browser password manager. The setup steps for Bitwarden are in the Bitwarden Chrome extension guide, and the move itself is in how to move Chrome passwords to Bitwarden.

I have not tested Bitwarden against the same malware case, and I am not claiming it is immune to it. A dedicated manager still runs on the same computer. Whether it holds up better than Chrome against an infostealer is a claim I would need a primary source for.

What I could not check

I did not verify which encryption mode your Google account uses by default. I did not verify whether Chrome now protects passwords with App-Bound Encryption. I did not read the Chromium source for its password storage. I did not test any attack. Everything above is what Google’s pages say, on the dates I read them.

How this was checked

I read Chrome Help on managing passwords and on how Chrome protects passwords, Google Account Help on on-device encryption, and the Google Online Security Blog post of 30 July 2024, on 11 October 2026. No software was run.

Do this today

Open Google Password Manager, run the Checkup, and change what it flags. Then open the on-device encryption page and find out which mode you are in. If you decide a dedicated manager is the better fit, start with the extension and move the passwords across in that order.

Resources

Tell me where I am wrong

Your email is not published and I do not add it to any list. Corrections with a source are the ones I act on fastest.