What cloud sync and a CSV export can still hold after you save a password in the browser

“Saved” is not “only on this computer”

A lot of people treat the browser’s Save button as a sticky note on this machine: this PC remembers, other machines do not. What actually happens is more concrete. The browser writes the site, username, and password as one autofill record. That record first appears in the current profile. If you already turned on sync with a Google, Microsoft, or Mozilla account, the same record can also appear on other devices signed into that account, under each vendor’s rules. The previous note covered a related hop: a password left on the system clipboard can still sit in cloud sync and history. Clicking Save is the same class of exposure. The recipient is no longer the operating-system clipboard. It is the browser password store, the account in the cloud, and the file you export.

Login passwords, mailbox passwords, drive passwords, and admin passwords are all content that should not grow extra copies outside the current form without you noticing. The question is not “is this browser clever.” It is “did this Save hand plaintext that should have stayed in the current form to the next store.” A product page that says “encrypted” only answers whether someone on the path can eavesdrop, and whether the on-disk vault is ciphertext. When you check, also ask who holds the decrypt key, which other devices share the account, and whether the export button unfolds that ciphertext back into text.

This note stays with Google’s Password Manager and Chrome sync pages, Microsoft’s Edge export warning, Mozilla’s Firefox export warning, and Apple’s iCloud Keychain security overview, because those layers are written in public language you can check. Enterprise policy, a third-party “password export” extension, and an older settings screen add another layer, and product pages rarely spell that layer out in the same sentence. When you change browsers, walk that version’s settings again. Do not paste passwords.google.com onto another vendor’s sync switch.

Local store, account sync, and the export file are three different layers

Hearing “is it safe to save a password in the browser” as a yes-or-no question drops at least three layers. The first is the local store. You click Save, and the entry enters the current browser profile. Closing this tab does not clear that layer: the store lives in the profile directory, not in that tab’s memory. When you are not signed in, Chrome Help is blunt: bookmarks and other info are saved only on your device, not in your Google Account.

The second is account cloud sync. Get your bookmarks, passwords, and more on all your devices says that when you sign in to Chrome, you can save info in your Google Account, and then use that info on all your devices where you are signed in with the same account. When you sign out of Chrome, “your info is kept safe in your Google Account and removed from the device.” The local copy can leave. The account copy stays. Apple takes a different path. iCloud Keychain syncs inside a circle of trust. The transfer is end-to-end encrypted, so Apple cannot read the plaintext, but every trusted device in the circle can decrypt.

The third is the export file. This is not “one more ciphertext copy of the sync blob.” It is official plaintext on disk. Google requires import as .csv and says the first line should include url, username, and password. Edge and Firefox each describe that file as unprotected or readable to anyone. Sync is tied to an account and to devices. Export is tied to whoever can open the text sitting in Downloads.

Google: the default key sits in the account; two other switches change that sentence

Google writes the default model into Get started with on-device encryption. The metaphor is a safety deposit box: you lock the valuables, and the bank looks after the key. Standard encryption scrambles saved passwords or passkeys with a unique key. Google stores the key used to access those passwords in your Google Account, and uses it to decrypt in these cases: when you open them on passwords.google.com, on eligible devices, or in Chrome settings; and when Password Checkup looks for security issues. The official meaning is one short sentence: this type of encryption means that you trust Google to hold the key and keep your data secure.

On-device encryption changes who holds the key. The same page says that after you set it up, you still lock passwords or passkeys with Google Password Manager, but you take the key with you. Only you can see your data. You unlock with your Google password, or with the screen lock on a compatible phone or tablet. The sentence becomes: only you have the key to unlock data such as passwords or passkeys. It also writes the cost: once on-device encryption is set up, it cannot be removed; if you lose the key, you could lose the passwords. That switch is not on by default. Until you turn it on, the sentence that applies is “the key sits in the account,” not “only you can see it.”

A sync passphrase is a third model, and it covers more. Chrome sync Help says that with a passphrase you can use Google’s cloud to store Chrome data without letting Google read it. Payment methods and addresses from Google Wallet are not encrypted by that passphrase. After you create one, a new device needs the passphrase to sign in; you can no longer check saved passwords on passwords.google.com, and you cannot use Smart Lock for Passwords. On-device encryption covers passwords and passkeys only. A sync passphrase covers all of the Chrome data you sync to Google. Neither switch is required. If both are off, the sentence that applies is still the bank holding the key.

Once sync is on, the trust boundary is the account, not this computer. Chrome Help lists what you can save to the account after sign-in: bookmarks, reading list, passwords, payment info, identity docs and contact info, extensions, web apps, settings, and optional tabs and browsing history. Sign into another computer with the same Google Account and turn sync on, and that computer becomes a receiver. The old laptop at home that never signed out, and the work PC that once signed into a personal Chrome profile, sit inside that boundary. Sharing one Google Account with a family member expands this Save to every device they can open.

Apple: end-to-end stops Apple from reading plaintext; it does not stop devices in the circle

Apple names the feature iCloud Keychain. The security overview states the goal in plain language: sync passwords between iPhone, iPad, Mac, and the rest of the Apple devices without exposing them to Apple. Keychain items travel through Apple servers from device to device, but they are encrypted end-to-end so that Apple and other devices cannot read their contents. The design also requires that passwords stay protected if the user’s Apple Account is compromised, if iCloud is compromised by an external attacker or an employee, or if a third party accesses the account.

“Other devices cannot read” means devices outside the circle of trust. Secure keychain syncing says that each device keeps a local list of the user’s other syncing identities. Each synced item is encrypted so that only a device in the user’s circle of trust can decrypt it; no other device, and not Apple, can. Safari usernames, passwords, and credit card numbers, plus Wi-Fi passwords, are marked as synchronizable. A new device joins the circle by pairing with an existing device, or through keychain recovery. Encryption stops eavesdropping on the path and stops Apple from reading plaintext. It does not stop “the iPad you already agreed to add.”

When you compare the two “encrypted” sentences, do not hear them as the same claim. Google’s default is “the bank holds the key.” Apple Keychain’s default is “only devices in the circle can decrypt.” Both products treat devices on the same account as trusted endpoints. One extra computer that never signed out is one extra place this Save can autofill. Sharing an Apple Account, like sharing a Google Account, expands the trust boundary. It is not “one more ciphertext backup that only you can read.”

Exported CSV: all three vendors call it readable to anyone

When you migrate or back up, each vendor offers an export. The end of that path is not another ciphertext vault. It is text on disk. Google’s Import or export passwords and passkeys page writes the import format as .csv and says the first line should include url, username, and password. You can import 3,000 passwords at a time and store up to 10,000 in the Google Account. The export path is Chrome → Passwords and autofill → Google Password Manager → Settings → Export passwords → Download file. Step 3 after import is written on its own line: delete the .csv password file on the device. The important note is: if you do not delete the password file, anyone who uses the device can open the file and access your passwords.

Microsoft’s sentence is shorter. Export passwords in Microsoft Edge says you can export saved passwords from desktop Edge to a CSV; you cannot export from Edge on Android or iOS. The caution is: passwords exported to a CSV are not protected and will be visible to anyone who can see the exported file. After you have used the file, it strongly recommends pressing Shift+Delete to permanently delete it. That does not affect passwords still stored securely in Edge. A copy that only went to the Recycle Bin can still be restored after a normal delete—that is why the page writes permanent delete.

Firefox puts “no longer encrypted” into the warning itself. Export login data from Firefox says that after you export to .csv, the passwords will not be encrypted and will be in a readable form to anyone who can view the file; do not upload it online, email it, or share it; delete the file when finished. The dialog reminds you that passwords will be saved as readable text. If a Primary Password is on, you enter it before the export. That password gates about:logins. It does not gate “who can open the file after it is already on disk.”

The three warnings point at the same hop: export is a plaintext landing. If Downloads is also a folder a drive client syncs, the CSV can be uploaded again. The previous note on an unencrypted file dropped into a drive covered what a provider, a sync client, and a content-hash shortcut can still see. Here the password column is that plaintext. Email, chat, and a sharing link each copy “readable to anyone” one more time. None of the official pages describe this CSV as “still encrypted, just a different extension.”

Check it here: the other signed-in device, or the CSV in Downloads

“I only saved it in my own browser” is not proof. Split the check into steps you can finish on this machine. Each step answers one question.

1. Write a canary that will never appear in real work. If you need random characters, draw 6–128 from the password generator (default 16; below 8 the page warns that the string is weaker). Treat that output as a canary, not as a new login password. Do not use a password you still use.
2. In Chrome, trigger Save Password on a disposable practice page or a local form, and save only the canary. Open Settings → You and Google and see whether passwords are among the info saved to the account. On another device signed into the same Google Account with sync on, see whether autofill or Password Manager shows the same entry. If it does, layer two already wrote the account.
3. Open passwords.google.com (or Google Password Manager inside Chrome). If you can see the canary there, the model in force is the default, or you already authenticated and decrypted—not “a sync passphrase is on, so the web vault is dark.” Then open the on-device encryption and encryption-options pages and see which sentence applies: the key sits in the account, only you hold the key, or you encrypt all Chrome data with your own passphrase.
4. Export only the canary. Follow the official path, download the CSV, and open it in a text editor. Confirm that url / username / password and the canary plaintext are there. Do not leave the file in a folder a drive client syncs. Do not paste it into chat. When the check is done, delete the way each vendor recommends: Edge writes Shift+Delete; Google and Firefox write delete it immediately. Then check the Recycle Bin and Recently Deleted.
5. If you use Safari or other Apple devices, go to another device already in the same iCloud Keychain circle of trust and see whether it can autofill the canary. If it can, a copy inside the circle is already there. That is a different fact from “Apple can or cannot read plaintext.” When you finish, delete the canary entry on every device that received it.

The first hop—whether this device handed plaintext to the browser store—is a different question from How to verify browser encryption: prove plaintext never left. Here the string almost always leaves the current form, because Save means write to a password store. This note asks which layers it entered after that. The canary should appear only on your own password page, on your own synced devices, and in the one file you chose to export. If it appears on an old PC you thought was signed out, on a family tablet, or in a Downloads copy a drive client already uploaded, the trust boundary is larger than “this browser.”

Treat Save as another exposure, using a generator that opens with no account

If you want to generate locally first, then decide whether to hand the string to the browser at all, you do not need to register, and you do not hand the string to MakePwd. Open the password generator, draw a disposable random string, copy or write it down on this page only, and use the section above to decide whether to click the browser’s Save. Generation and the strength hint finish in this tab. Newly generated passwords are not uploaded. Every tool opens with no account. There is no password vault that keeps the string for you—MakePwd will not sync it to the cloud after you click Save.

The generator answers “where did this string come from.” It does not answer “will the browser sync it after Save.” If you want to know whether a password you already use is weak or sits on the local frequent-password list, use Password Audit. The password under test is not uploaded either, and the result is not a web-wide breach lookup. When another person needs the password, do not rely on “I saved it in the browser, then they sign into the same account”—that adds them to the trust boundary. A better path is to send it once with Burn-Link: the key sits in the URL # fragment and is not sent to the server over HTTP. Create and read are both public. The server only stores ciphertext for a short time.

FAQ

If I click Save Password, can Google read the plaintext?

Under the default model, yes, along the path Google publishes. Account Help says standard encryption stores the key used to access your passwords in your Google Account. Google decrypts with that key when you open passwords.google.com, an eligible device, or Chrome settings, and when Password Checkup looks for security issues. The official meaning is that you trust Google to hold the key. Turn on on-device encryption and the sentence becomes: only you have the key. Set a sync passphrase and Google writes that it cannot read the Chrome data that passphrase covers, and you can no longer view saved passwords on passwords.google.com.

Is an exported password CSV still encrypted?

All three official pages describe it as no longer protected. Google says that if you do not delete the file, anyone who uses the device can open it and access your passwords. Edge says passwords exported to a CSV are not protected and will be visible to anyone who can see the file; after you finish, it recommends Shift+Delete so the file is permanently erased. Firefox says the exported file will not be encrypted and will be readable to anyone who can view it; do not upload it, email it, or share it, and delete it when finished.

If I close the browser on this PC, are the saved passwords gone?

Closing the window does not clear the copy that already went into the account. Chrome Help says that after you sign in, you can save passwords to your Google Account and use them on every device signed in with the same account. If that info was never saved to the account, bookmarks and other data stay on this device only. When you sign out of Chrome, the info is kept safe in the Google Account and removed from the device—the account copy remains. Apple’s iCloud Keychain syncs inside a circle of trust: devices in the circle can decrypt; Apple cannot read the plaintext.

Is a password saved in the browser the same check as a local weak-password list?

No. Google’s Password Checkup runs on saved entries. Under standard encryption, Google holds the decrypt key in order to do that. MakePwd Password Audit keeps the password under test in the current tab, compares it with a local frequent-password list, and does not upload it. It is not a web-wide HIBP lookup. A miss only means this list did not match. Saving in the browser is a different trust boundary: synced devices and the export file.

Three things to remember before the next Save

First, “Saved” only means the entry entered the browser password store. It does not mean the string exists only on this computer. Second, the local store, account cloud sync (Google’s default key sits in the account; on-device encryption and a sync passphrase change that sentence; Apple Keychain is end-to-end inside the circle), and the exported CSV (all three vendors call it readable to anyone) are three different leftover copies. Closing the window only touches the local UI. It does not touch the account or the file on disk. Third, check with a disposable canary against the other device, passwords.google.com, and Downloads. Do not experiment with a real login. When the export check is done, permanently delete the file the way the vendor recommends.

If the next question is what the clipboard can still hold after Copy, read What clipboard history and cloud sync can still hold after you copy a password. When you need to prove in Network that plaintext never left this device during encryption, read How to verify browser encryption: prove plaintext never left. What a local list can prove—and why it is not a web-wide breach lookup—is in What a local weak-password list can prove—and why it is not a web-wide breach lookup. This note only draws a line you can write into a conclusion: what cloud sync and a CSV export can still hold after you click the browser’s Save.