Every sync service encrypts your data in transit and at rest. That sentence appears in every privacy policy and it is true everywhere, which is exactly why it tells you nothing. Encryption at rest with provider-held keys protects against a stolen hard drive in a datacenter. It does not protect against the provider reading the data, an attacker who compromises your account, or a legal demand served on the company. The property that changes those outcomes is end-to-end encryption: keys derived on your device, never available to the server. Some browsers offer it by default, some as an option, and one only for certain data types.
Chrome: Google holds the keys unless you change a setting
In its default configuration, Chrome sync encrypts your data with keys that Google manages. That design enables the convenience features: you can see your saved passwords at passwords.google.com, and your data survives a forgotten password because Google can always re-key it for you. The cost is symmetrical. A provider that can recover your data for you can produce it for someone else, and if you enable the relevant account settings, your synced Chrome history can also feed personalization across Google services.
Chrome does offer real end-to-end encryption behind an option called a sync passphrase. Set one and your synced data is encrypted with a key derived from that passphrase before upload; Google cannot read it. The trade-offs are stated plainly in Google's own documentation: no viewing passwords on the web, some features that depend on server-side access stop working, and if you forget the passphrase your sync data is unrecoverable and must be reset. That last part is not a flaw. Unrecoverable-by-the-provider is what end-to-end encryption means.
Firefox: end-to-end by design, with one sharp edge
Firefox Sync is end-to-end encrypted by default and has been since the current protocol, known as onepw, replaced the older pairing system. Your Mozilla account password is stretched on your device using PBKDF2 and used to unwrap an encryption key called kB; sync data is encrypted with keys derived from kB using HKDF, with AES-256 and HMAC protecting the records. Mozilla's servers store only wrapped keys and ciphertext. The design goal, documented in Mozilla's protocol specifications, is that the server never sees your password or your keys.
The sharp edge follows directly from the design: if you forget your password and reset it without a recovery key, your synced data is gone, because the old password was the only path to kB. Users hit this and file angry bug reports. It is the system working as specified. Set up the recovery key.
You can classify any sync service with one question: if you forget your password, can the provider get your data back? If yes, the provider holds keys, and so can anyone who successfully compels or compromises the provider. If no, you are looking at end-to-end encryption.
Safari: end-to-end for some categories, not others
Apple's model is the least uniform, because iCloud applies different protection levels per data category. Under standard iCloud protection, iCloud Keychain, which holds your Safari passwords, is end-to-end encrypted, and Apple documents Safari browsing history and iCloud Tabs in the end-to-end encrypted category as well. Safari bookmarks, however, are covered by Apple-held keys under standard protection. They only become end-to-end encrypted if you enable Advanced Data Protection, the opt-in mode Apple introduced in December 2022 that extends end-to-end encryption to most iCloud categories, including iCloud Backup.
The backup point matters more than it looks. On Apple and Android alike, a cloud device backup can contain app data that is otherwise strongly protected on the device, so the protection level of the backup becomes the protection level of the data. If you care about the sync question, you also care about the backup question; they are the same question wearing different clothes.
Brave: a sync chain and no account at all
Brave Sync takes the most conservative position. There is no account and no password. Devices join a "sync chain" by sharing a 24-word seed phrase, generated on-device using the same BIP39 word list familiar from cryptocurrency wallets, and everything synced is encrypted client-side with keys derived from that seed. Brave's servers relay and store ciphertext they cannot decrypt, and there is no recovery mechanism whatsoever: lose access to every device in the chain and the seed, and you start a new chain.
The comparison in one table
| Browser | Default | End-to-End Option | Cost of the E2E Path |
|---|---|---|---|
| Chrome | Provider-held keys | Sync passphrase | No web password access, some features disabled, no recovery |
| Firefox | End-to-end (onepw) | Default | Password reset without recovery key wipes data |
| Safari | Split by category | Advanced Data Protection | Opt-in setup, recovery contact or key required, some web access reduced |
| Brave | End-to-end (sync chain) | Default | Lose the chain, lose the data; no account recovery exists |
What is actually at stake in a sync store
It is worth being concrete about what this data reveals. Browsing history is a behavioral record detailed enough to reconstruct health concerns, relationships, finances, and location patterns. Saved passwords are the keys to everything else. Open-tab sync reveals what you are doing right now. When this sits server-readable, three parties can potentially reach it: the provider itself, under whatever its policies and business incentives allow; a government, through legal process served on the provider; and an attacker who takes over the account, which is why infostealer malware prioritizes browser credential stores and session tokens above almost everything else on an infected machine.
End-to-end encryption removes the first two from the server side entirely and limits the third to devices, which is where your defensive effort then belongs. It does not make sync safe against malware on an endpoint you own; nothing does, because your own device legitimately holds the keys.
What to do about it
- If you use Chrome sync, decide deliberately: either accept the provider-held-key model or set a sync passphrase and store it in a password manager.
- If you use Firefox, generate and store the recovery key. The E2E design makes password loss unforgiving.
- If you live in Apple's ecosystem and the contents of your bookmarks and backups matter to you, enable Advanced Data Protection and complete the recovery setup it requires.
- Consider keeping passwords out of browser sync entirely and using a dedicated password manager, which decouples your most sensitive secrets from your browsing profile.
- Whatever browser you choose, know that browser privacy and sync privacy are separate properties. A browser can block trackers admirably and still upload readable history.
The pattern across all four vendors repeats everywhere in cloud services, including messaging and email: convenience features and provider-recoverable keys travel together, and end-to-end encryption always costs something in recoverability. The vendors that state that cost plainly, and make the trade explicit, are the ones taking your side of the trade seriously.