“End-to-End Encrypted” vs “Encrypted”: They Are Not the Same Thing

By ShareDrop.org Engineering · Published 2026-08-29

Almost every service that touches your files now says “encrypted.” The word is true and, on its own, nearly meaningless: a file can be encrypted on the way to a server, encrypted on the server's disks, and still be readable by that server in between. The phrase that actually tells you something is who holds the keys. This article separates the three things “encrypted” can mean and shows how to tell which one a product is claiming.

Three different promises

Phrase	What is protected	Who holds the key	Who can read the file
Encrypted in transit	The connection between you and the service (TLS, the padlock in the browser)	Your device and the server, per connection	You, the recipient, and the service
Encrypted at rest	The file while stored on the service's disks	The service	You, the recipient, and the service (it decrypts to serve it)
End-to-end encrypted	The file from your device to the recipient's device, through anything in between	Only the two endpoints	You and the recipient only

In transit and at rest are important: they stop eavesdroppers on the network and thieves who walk off with a disk. But they protect the file from outsiders, not from the service. If a company can show you a preview, run a virus scan, generate a thumbnail or comply with a request to hand the file over, it holds the key, and the file is not end-to-end encrypted, whatever the marketing page says.

The test that settles it

Ask one question: if the service's servers were fully compromised, could the attacker read my file? For in-transit and at-rest encryption the answer is yes — the keys are on those servers. For end-to-end encryption the answer is no, because the servers never had the keys. Everything else is detail.

A practical corollary: any feature that requires the service to understand the file (search inside documents, image previews, “smart” organisation, content moderation) is incompatible with end-to-end encryption. When a product offers those and also claims end-to-end, one of the two claims is wrong.

What end-to-end looks like in practice

End-to-end encryption needs the two endpoints to agree on a key without any middle party learning it. Modern systems do this with a key exchange: each side generates a key pair, they swap public halves, and both derive the same shared secret that nobody on the path can compute. In a WebRTC transfer, that exchange is the DTLS handshake between the two browsers, and it happens whether the packets travel directly or through a relay: the relay forwards ciphertext it cannot open (the mechanics).

There is one gap end-to-end encryption cannot close by itself: how do you know the “other end” is really the person you think, and not someone who intercepted the key exchange? That is what a safety code is for: a short string derived from both sides' keys that you compare out of band (how it works). Encryption keeps the conversation private; the safety code confirms who you are having it with.

A worked example: one file through a cloud drive

Upload. Your browser opens a TLS connection to the provider and sends the file. Encrypted in transit: nobody on the network can read it. At the far end the provider's server decrypts it — it has to, to receive it.
Storage. The server encrypts the file with a key the provider manages and writes it to disk. Encrypted at rest: a stolen disk is useless. The provider can decrypt it whenever it needs to: to make a thumbnail, index it for search, scan it, or answer a legal request.
Download. The recipient's browser opens its own TLS connection; the server decrypts the file from storage and sends it. Encrypted in transit again.

The file was encrypted at every moment of that journey and readable by the provider at two of them. Nothing was mishandled; that is simply what “encrypted in transit and at rest” means. Some providers offer client-side encryption as an option, which changes step 1: the browser encrypts the file with a key derived from your password before uploading, and the provider stores something it cannot open. The tell is what you lose: no previews, no search inside files, and no password recovery.

What zero-knowledge providers actually do

“Zero-knowledge” means the provider designs itself out of the key path. Your password never leaves the device; a key is derived from it locally; everything is encrypted before it goes up. Sharing a file with someone means encrypting its key for them, which is why share links from such services carry a secret fragment after the # that the browser never sends to the server. The same design makes the two limitations non-negotiable: forget the password and the data is gone, because there is nobody who can decrypt it; and the server cannot show you a thumbnail of a file it cannot read. A provider offering both zero-knowledge and password reset is describing two different products, or one of them inaccurately.

Questions to ask a vendor

If I forget my password, can you recover my files? (The honest end-to-end answer is no.)
Can your staff or systems produce a preview, a thumbnail or a search index of my file contents? (If yes, they can read them.)
Who holds the keys, and where are they stored?
Has the encryption design been reviewed by an outside party, and is the client code available to inspect?
What metadata (file names, sizes, sharing graph) is visible to you even when content is not?

Metadata is rarely end-to-end

Even a genuinely end-to-end service usually sees file names, sizes, timestamps and who shares with whom, because it needs them to run. Some encrypt names; almost none hide sizes or the sharing graph. A peer-to-peer transfer has the smallest possible metadata footprint because no service holds the file at all: the signaling server learns that two devices connected, and nothing about what passed between them (the full map, party by party).

Three tests you can run yourself

Try the password-reset flow. If the service can restore your account and your files after you have “forgotten” the password, it holds the keys.
Look for previews. Open a file's page on the web without downloading it. A rendered thumbnail of a photo or the first page of a PDF means the server read the file.
Search inside a document. If the web interface can find a word inside your files, it has indexed their contents, which requires reading them.

Passing all three does not prove end-to-end encryption, but failing any one disproves it, whatever the marketing page says.

How to read a product page

“Encrypted” with no qualifier almost always means in transit, sometimes at rest. Assume the service can read the file.
“Bank-grade” or “military-grade” describes the cipher, not who holds the key. AES-256 protects a file perfectly well from everyone except whoever has the AES key — and that is the whole question.
“Zero-knowledge” or “end-to-end” is the real claim. Look for two supporting facts: the service says it cannot recover your data if you lose your password, and it offers no preview or search of file contents.
“Encrypted at rest with your own key” is a genuine step up for storage, but the file is still decrypted to send it to a recipient unless the recipient also has the key.

Where common tools sit

Tool	In transit	At rest	End-to-end
Email	Usually (TLS between servers)	Provider-held keys	No, unless you use PGP/S-MIME
Cloud drives (default)	Yes	Provider-held keys	No
Upload-and-link services	Yes	Provider-held keys	Usually no; a few offer it as an option
Signal, WhatsApp messages	Yes	On device	Yes
WebRTC P2P transfer	Yes (DTLS)	Nothing stored	Yes, by protocol design

None of these are “insecure.” They protect against different people. The right choice depends on whether the party you are worried about is a stranger on the network, a thief with a disk, or the service itself: see what each party can observe for the full map.