End-to-End Encryption: What It Actually Means
The term is used loosely enough to be meaningless. Here is the precise definition, how to tell whether a product really offers it, and what it costs you.
"End-to-end encrypted" appears on the marketing pages of products that mean entirely different things by it. Some mean HTTPS. Some mean disk encryption at the hosting provider. A few mean the strict thing. The distinction matters, because only one of them changes who can read your document.
The definition that matters
End-to-end encryption means the content is encrypted before it leaves the sender’s device and can only be decrypted by the intended recipient. The service carrying it never holds the key, so it cannot read the content — not for support, not for search, not under subpoena, not if it is breached.
That last clause is the whole point. Encryption in transit protects against someone watching the network. Encryption at rest protects against someone stealing the disks. Neither prevents the provider itself from reading your file, because in both cases the provider holds the keys.
Three things frequently mislabelled as end-to-end
If a product claims E2EE, these are the usual substitutions.
- TLS/HTTPS: protects data moving between your browser and the server. The server still decrypts it on arrival.
- Encryption at rest: the database or disk is encrypted, but the service decrypts it whenever it needs to serve, index, or search your content.
- Server-side encryption with managed keys: the provider encrypts your data with keys the provider also controls — which is a lock whose key is taped to the door.
How to test the claim
You do not need to read the source code. Ask what the product can still do with your content, because capability reveals key custody.
- Can it show a preview or thumbnail of the document on the server? Then it can read it.
- Can it search inside your content? Then it can read it.
- Can it run AI features over the content server-side? Then it can read it.
- If you lose the link or key, can support recover the content? Then they hold a key.
What end-to-end encryption costs
Honest answer: real E2EE takes features away. If the server cannot read the content, it cannot generate previews, index it for search, scan it for malware, or answer questions about it. Recovery becomes impossible by design — lose the key and the content is gone, permanently, and nobody can help you.
That is why sensible products make it a choice rather than a global default. Most documents benefit more from convenience; some documents justify giving up every server-side feature.
How Capsule handles it
Capsule offers end-to-end encryption as a per-share option. When you enable it, the document is encrypted in your browser with AES-256-GCM and the key is placed in the part of the link after the # — the fragment, which browsers never transmit to the server. We store ciphertext and cannot decrypt it.
When you do not enable it, your content is encrypted in transit and at rest, and our servers can read it — which is what makes previews, search, and the optional AI chat possible. We would rather describe that plainly than claim a stronger guarantee than the code delivers.
One consequence worth knowing: an encrypted share is a snapshot taken when you created the link. Later edits do not reach the recipient, because we cannot re-encrypt content we cannot read.
Keep reading
- Why Email Attachments Are a Security Risk
Email was never designed to carry confidential files. Here is what actually happens to an attachment after you hit send, and what to use instead.
- Best Practices for Sharing Sensitive Files in 2026
A practical checklist for sending confidential documents: expiry, view limits, verification, audit trails, and the mistakes that undo all of them.