What Is End-to-End Encrypted File Sharing? A Beginner's Guide

You've probably heard the term "end-to-end encryption" (E2E or E2EE). It's a security feature WhatsApp and Signal advertise, but many people are unsure what it actually means. This guide explains what end-to-end encryption is and why it matters for file sharing.

Regular Encryption vs End-to-End Encryption

Regular Encryption (TLS/HTTPS)

Most websites are encrypted via HTTPS. The flow looks like:

You → [Encrypt] → Server → [Decrypt] → [Re-encrypt] → Recipient

Data is encrypted in transit, but the server can decrypt and read it. Email, Google Drive, and most cloud services work this way.

End-to-End Encryption (E2EE)

End-to-end encryption is different:

You → [Encrypt] → Server → Recipient → [Decrypt]

The server can never decrypt the data. Only the sender and recipient can see the original.

Why End-to-End Encryption Matters

1. Safe Even If the Server Is Hacked

If the server is breached, attackers only get encrypted data. Without the key, it's meaningless bytes.

2. Even the Service Provider Can't Read It

Companies like Google or Microsoft technically have access to data on their servers. With E2E encryption, even they can't read your files.

3. Protected from Government/Law Enforcement Requests

If a company is asked to hand over data, all they can give is encrypted bytes.

4. Prevents Insider Access

Stops curious or malicious employees from looking at user data.

What E2E Encryption Means for File Sharing

Regular file sharing (Google Drive, Dropbox, etc.):

Item	Possible?
Server decrypts files	✅ Yes
Provider can read files	✅ Yes
Originals exposed if hacked	✅ Risk
Can be handed to law enforcement	✅ Yes

End-to-end encrypted file sharing (Tresorit, Sync.com, etc.):

Item	Possible?
Server decrypts files	❌ No
Provider can read files	❌ No
Originals exposed if hacked	❌ Safe
Can be handed to law enforcement	❌ Encrypted bytes only

How E2E Encryption Works

Take a LOCK.PUB request link as an example — the one LOCK.PUB feature built this way:

1. Setup: Your browser generates a key pair and locks the private half with your unlock password. The password itself never leaves your device
2. Upload: The sender's browser encrypts their submission to your public key before anything leaves their device
3. Storage: On the server the submissions sit as ciphertext and your private key stays locked by your password, while practical details like the form's own wording and each sender's name remain readable. Your unlock password is never stored
4. Decryption: You open submissions in your own browser with your unlock password. The submitted content itself is ciphertext we cannot read

Caveats of E2E Encryption

End-to-end encryption is powerful but has limitations:

1. No Recovery for Forgotten Passwords

The server doesn't know your password, so if you forget it, the file is permanently inaccessible. This isn't a flaw — it's proof of true E2E encryption.

2. Weak Passwords Defeat the Purpose

Passwords like "1234" can be cracked by brute force. Use strong passwords.

3. The Recipient's Device Must Be Secure

If the recipient's computer is compromised, decrypted files can be exposed. Encryption protects a file everywhere except on the device where it is opened, so keep that device locked and up to date.

Which Services Are Actually E2E Encrypted?

Service	E2E Encrypted?
Google Drive	❌
Dropbox	❌ by default (optional E2EE team folders on top business plans, no shared links)
OneDrive	❌
WeTransfer	❌
Tresorit	✅
Sync.com	✅
LOCK.PUB (request links)	✅
LOCK.PUB (file links)	❌ Password-based
Signal (messenger)	✅
WhatsApp (messenger)	✅

LOCK.PUB is honest about the split. Request links are end-to-end encrypted: the key pair is made in your browser, and the unlock password that opens the private half never reaches us. Ordinary file, memo and image links are encrypted on our servers with a key that needs both the password you choose and a server secret held outside the database, so stolen ciphertext on its own is not enough to open them. That is a far stronger guarantee than plain cloud storage: the contents of your files and messages are never stored as readable text — practical details like the file's name and the public label you choose stay readable, so your recipient knows what they are opening — and we never store the password itself.

Final Thoughts

End-to-end encryption isn't just a marketing term — it's a genuinely strong security model. Features inside one service can be encrypted in different ways, so check that the one you plan to use actually qualifies, and match it to the job.

If you need true E2EE, a LOCK.PUB request link generates the key pair in your browser and your unlock password never reaches us — free with a LOCK.PUB account, and the people sending you files need no account and no app at all. For everyday sharing, a password-protected file link is the simpler option: files are stored encrypted rather than as downloadable objects, we do not store your password and cannot recover it, and you can set an expiry date (Pro) so the link stops working after the day you choose.