TLS protects a file while it moves. It stops protecting it the moment it arrives. This is the distinction between transport encryption, encryption at rest, and end-to-end encryption performed in the browser — stated in terms of who holds the key at each stage, because that is the only question that separates them.
The padlock is about the pipe
When a browser shows a padlock in the address bar, most people read it as "this is private". What it actually says is narrower: the connection is encrypted, so nobody sitting between you and the server can read what passes along it.
That protection ends at the server's front door. The traffic arrives, the transport encryption is stripped, and the server holds your plaintext. From that moment the confidentiality of your file depends entirely on how the service stores and handles it — something the padlock says nothing about, because it was never describing that at all.
To know where you actually stand, ignore the connection and ask one question: who holds the key?
Three arrangements, one question
Transport encryption. The browser and the server negotiate a shared secret for the duration of the connection. Both ends hold it, which is the point — the server has to read what you send in order to act on it. Secure against anyone on the network; no protection at all against the service itself.
Encryption at rest. The service encrypts what it stores, and holds the key that opens it. This defends against a stolen disk or a leaked database dump. It does not defend against the service, because the service must decrypt your file to show it back to you. Anyone who can compel the service, or who obtains sufficient access inside it, obtains the plaintext with it.
End-to-end encryption performed in the browser. The key is derived on your machine and never sent. The browser encrypts before anything leaves it, and the server stores ciphertext it has no means of opening. It holds the package without being able to look inside.
The three are often described in the same vocabulary, which is why they blur together. They are not variations in strength. They are different answers to who can read your file, and the answer follows entirely from where the key lives.
What "the browser does it" actually means
Browser-side encryption rests on the Web Crypto API — the crypto.subtle interface that
lets JavaScript derive a key from a passphrase and encrypt with it locally. The ciphertext
goes to the server; the key does not.
There is a caveat here that deserves to be stated plainly rather than buried, because it is the weakest joint in the whole arrangement: the code doing the encrypting was delivered by the server you are protecting yourself from. Every page load fetches that JavaScript again. A build that quietly posted your passphrase somewhere would look identical from the outside.
So browser end-to-end encryption is a claim about a specific delivered build, not a permanent property of the service. It is meaningfully stronger than the alternatives, and it is not the same as a guarantee. What narrows the gap is anything that makes the delivered code checkable — published builds, reproducible ones, signatures, extensions that pin what they will run. What does not narrow it is the phrase "we cannot see your data" repeated with more confidence.
Zero-knowledge is a claim, not a mechanism
The term describes an outcome. It says nothing about how that outcome is reached, which is why it survives so easily in marketing copy. Three questions separate the services that mean it from the services that like the sound of it.
- Where is the key derived? On the server, and the service can read your files. In the browser, and it may not be able to — subject to everything in the previous section.
- What does the server store? Plaintext answers the question on its own. Ciphertext moves you to the third question.
- What happens when you forget your password? This is the one that cannot be talked around. A service that can restore your files after a full password reset necessarily holds a route to your key — an escrowed copy, a master key, something. The convenience and the property are mutually exclusive. If losing the password does not lose the data, somebody else can open it.
The third question is worth asking first, because it is answerable from a help page in about a minute, and it makes the other two mostly unnecessary.
Why the distinction sharpens over time
The stakes here are a function of retention. When data was transient the difference between these arrangements was close to academic. Now files sit on servers for years, across jurisdictions, through acquisitions and policy changes and breaches, and each of those is an opportunity for plaintext to be read by someone it was never shown to.
Transport encryption protects a file for the seconds it is in motion, which turns out to be the least of its life. What happens during the remaining years depends on a decision made before the file ever left the machine: whether anyone but you was ever in a position to open it.