Three places encryption can happen
"Encrypted" on a product page can mean very different things. The useful question isn't whether data is encrypted, but who holds the key at each point.
- In transit (TLS). The connection between your browser and the server is encrypted. That stops people on the network from reading the traffic, but the server receives your data in readable form.
- At rest (server-side). The server encrypts data before writing it to disk or backups, with keys the service manages. That helps against stolen disks and some storage leaks, but the service can decrypt whenever its software needs to.
- Client-side (end-to-end). Your device encrypts the data before it leaves, with a key the service never receives. The server stores and forwards ciphertext it can't read.
Side by side
| TLS in transit | Server-side at rest | Client-side | |
|---|---|---|---|
| Who holds the key | Your browser and the server, per connection | The service | You, and whoever you share it with |
| Can the service read the data? | Yes, once it arrives | Yes | No |
| Stops network snooping | Yes | Not on its own | Yes |
| Helps if the database leaks | No | Partly, if the keys are stored elsewhere | Yes: attackers get ciphertext |
| Server-side search, previews, recovery | Possible | Possible | Not without the key |
The trade-offs of client-side encryption
Client-side encryption costs features. The server can't search your content, generate previews, scan it, or recover it if you lose the key. For a password manager or a note-sharing tool that's the point. For a team wiki it's often the wrong trade.
It also moves trust rather than removing it. In a web app, the code that does the encrypting is downloaded from the same service every time you visit. If that code were tampered with, it could leak your data before encrypting it. Open-source code and the option to self-host reduce that risk; they don't eliminate it. Native apps face the same question with every update, just less often.
Choosing the right model
- Use client-side encryption when the service should act as a courier rather than a vault: passwords, API keys,
.envfiles, private notes, files only one person should open. ProtectedShare works this way: notes, EnvShare secrets, file drops and chat messages are encrypted with AES-256-GCM in the browser, and the security page lists what the server stores. - Server-side encryption is reasonable when the service has to process the data (search, collaboration, analytics) and you already trust it with access.
- TLS is the baseline for everything. On its own, it says nothing about who can read the data after it arrives.
When a vendor says "encrypted," ask which of the three they mean, and who holds the key. How zero-knowledge encrypted notes work walks through the client-side flow step by step.