End-to-end vs at-rest vs in-transit encryption
"Encrypted" is one of those words that sounds like an answer but is really the start of a question. Three phrases get used almost interchangeably in privacy pages - encryption in transit, at rest, and end-to-end - and they protect very different things. The distinction always comes down to a single question: who can read the plaintext, and at what moment? This guide walks through each type, what it genuinely defends against, and where it stops.
Why the distinction matters
Plaintext is the readable version of your data; ciphertext is the scrambled version that requires a key to reverse. When a service says it is "encrypted," it is telling you that ciphertext exists somewhere in the pipeline. It is not telling you where the plaintext appears, who has the key, or whether the company itself can read what you stored. Those are the details that decide whether encryption protects you from a thief, from a curious employee, or from the provider as a whole. The three terms below each answer that question differently, and knowing which one a service means is the difference between an informed choice and a hopeful guess.
Encryption in transit
In transit means data is encrypted while it moves between two points - typically your device and a server. This is what TLS provides, the technology behind HTTPS and the padlock icon in your browser's address bar. While your request is crossing Wi-Fi, your internet provider's network, and the wider internet, it travels as ciphertext, so anyone tapping the wire sees only noise.
The important limit is what happens on arrival. Once the data reaches the server, TLS has done its job and the server decrypts it back to plaintext to process it. Encryption in transit defends against a network eavesdropper - someone sniffing traffic on a shared network, or a hostile intermediary between you and the destination. It says nothing about what the provider does with your data after it lands. A service can be perfectly encrypted in transit and still read, store, and analyse everything you send, because the protection ends at the front door.
Encryption at rest
At rest means data is stored as ciphertext on the provider's disks rather than as readable files. If someone physically steals a drive from the data centre, or pulls a raw backup, they get scrambled blocks instead of your content.
Here is the catch that marketing rarely spells out: in the ordinary version of encryption at rest, the provider holds the keys. The server encrypts data as it writes it and decrypts it whenever it needs to - to show it to you, to index it for search, to scan it, or to answer a support request. So encryption at rest defends against stolen hardware and a narrow class of breaches where an attacker gets the disk but not the running system. It does not defend against the provider itself, a rogue insider with production access, or a lawful demand that compels the company to hand over what it can already read. The lock is real, but the provider keeps a copy of the key on the same premises.
End-to-end, and the zero-knowledge version of it
End-to-end encryption moves the encryption to the endpoints - your device and the recipient's - using a key the provider never receives. The plaintext is turned into ciphertext before it leaves your device, and it becomes readable again only on the far end. In between, including on the server, only ciphertext exists. When the provider genuinely never holds the key, this is often called zero-knowledge: the company can store and deliver your data while having no ability to read it.
The defensive jump is significant. End-to-end encryption protects against everything the previous two do - eavesdroppers and stolen disks - and adds the one they cannot: it protects against the provider. A breach of the server yields only unreadable blobs. A rogue employee finds nothing to read. A demand for content cannot be satisfied with plaintext the company does not possess. The trade is that recovery becomes impossible; if the only key is lost, the data is gone, because there is no second copy sitting with the provider.
Whatever a service calls its encryption, ask: "Who holds the key?" If the provider holds it - which you can usually confirm by checking whether support can recover your data - then the provider can read your content, and no amount of "at rest" or "in transit" language changes that. Only when the key never reaches the provider does "encrypted" mean the company cannot read it.
The three side by side
These layers are not rivals - a well-built service uses all three at once. But they answer different threats, and only one of them constrains the provider.
| Type | Who holds the key | Stops a network eavesdropper | Stops a stolen disk | Stops the provider reading it |
|---|---|---|---|---|
| In transit (TLS) | Both ends, per session | Yes | No | No |
| At rest | The provider | No | Yes | No |
| End-to-end | Only you and the recipient | Yes | Yes | Yes |
The marketing trap
Because all three are truthfully described as "encryption," a service can highlight the weakest layer and let you assume the strongest. A page that says "your data is encrypted" while showing a padlock is usually describing transit only. "Encrypted at rest" sounds reassuring but tells you the provider keeps the key. Even "end-to-end" is sometimes stretched to cover systems where the company can still recover your account, which quietly means it holds a key after all.
The defence is not to distrust every claim but to translate each one into a plain statement about the key. Encryption in transit becomes "protected from someone snooping the network." Encryption at rest becomes "protected if a disk is stolen, but the provider can still read it." End-to-end becomes "even the provider cannot read it." Read that way, the marketing sorts itself.
What most people actually need
For most everyday use, encryption in transit and at rest are a reasonable baseline, and you are trusting the provider not to misuse what it can read. That trust is fine for plenty of low-stakes data. But when the content is genuinely sensitive - a password, a private document, something you would not want a breach or an insider to expose - you want the layer that removes the provider from the equation entirely.
classified is built with all three layers, and the third is the point. Traffic to the app runs over HTTPS, so it is encrypted in transit. The blobs sitting on the server are ciphertext, so it is encrypted at rest. And it is end-to-end because the encryption happens in your browser with AES-256-GCM before anything is sent, and the decryption key never reaches the server - it rides in the link's URL fragment or is derived from a password only you know. Only ciphertext and an opaque identifier reach the server, there is no content logging, and each note or file self-destructs after a single view or download. Because the key stays off the server, the company that runs the service cannot read what you shared - which is exactly the guarantee the first two layers cannot give on their own.
- "Encrypted" alone tells you almost nothing - the real question is always who holds the key.
- In transit (TLS) stops network eavesdroppers, but the server sees plaintext once data arrives.
- At rest stops a stolen disk, but the provider holds the key and can still read your data.
- End-to-end is the only layer that stops the provider itself, because the key never reaches it.
- A strong service uses all three; check whether support can recover your data to see who holds the key.
classified puts all three layers together: HTTPS in transit, ciphertext at rest, and end-to-end encryption in your browser with a key the server never sees.
Try classified free