How we built zero-knowledge PDF sharing in the browser

#privacy #security #showdev #webdev

Most “secure file sharing” tools still follow the same pattern:

upload your file
process it on a server
generate a link

Even if they mention encryption, the file usually exists on a server at some point.

We wanted to explore a different model:

👉 What if the server never sees the actual file?

⚠️ The problem with traditional file sharing
In a typical setup:

You upload a file
The server stores it
Encryption may happen server-side
You share a link

This creates a few issues:

your file is stored somewhere you don’t control
you rely on deletion policies
you trust how encryption is implemented

Even with “secure” tools, trust is still required.

🔐 A different approach: client-side encryption
Instead of sending raw files to a server, we flipped the flow:

File is encrypted in the browser
Only encrypted data (ciphertext) is sent
Decryption happens on the recipient’s side
The server never sees the original file

This is often called a zero-knowledge model.

How it works (simplified)
At a high level:

User selects file
→ Browser generates encryption key
→ File is encrypted locally (Web Crypto API)
→ Encrypted blob is uploaded
→ Shareable link contains access info
→ Recipient decrypts in browser

Key points:
encryption happens before any network request
keys are generated client-side
server only handles encrypted data
no plaintext file is ever stored

🔑 Key management
This is where things get tricky.

You have a few options:

embed the key in the URL (simple, less strict security)
share key separately (more secure, worse UX)
derive key from password (balanced approach)

Each choice affects:

👉 usability vs security

There’s no perfect answer — only tradeoffs.

⚖️ Tradeoffs we encountered
Building this model surfaced some real constraints:

1. UX complexity
Users expect “upload → share → done”

Adding encryption introduces:

key handling
potential confusion
edge cases

2. Performance
Encrypting large files in-browser:

uses CPU
can block UI if not handled properly

Solution:

streaming / chunking
Web Workers (optional)

3. No server-side processing
You lose:

preview generation
indexing
content-based features

Because:
👉 the server literally cannot read the file

💡 When this model makes sense

Client-side encryption is ideal when:

privacy matters more than convenience
files are sensitive
you want to minimize trust

Less ideal when:

you need heavy processing
collaboration features are required
speed is the top priority

🚀 Final thoughts
Most tools optimize for:

👉 speed
👉 features
👉 convenience

Very few optimize for:

👉 not having access to your data at all

Building a zero-knowledge model is possible today — especially with modern browser APIs — but it forces you to rethink product design from the ground up.

If you’re building anything around files, it’s worth asking:

Does your server actually need to see the data?

We’ve been experimenting with this approach for secure PDF sharing here: