Browser-Side Encryption: How It Removes Servers From the Trust Chain

The location of where encryption happens is more important than what algorithm runs. Encrypt on the server: the server can decrypt. Encrypt in the browser: only the browser owner can. That one architectural choice separates real privacy from privacy theater.

The two places encryption can happen

When you upload a file to any service, encryption can happen in one of two places:

1. Server-side. File travels over HTTPS to the server. Server encrypts it before writing to disk. Server holds the key. Server can decrypt any time.
2. Browser-side (client-side). Your browser encrypts before uploading. The server only ever sees ciphertext. The key never leaves your device.

Almost every consumer service does option 1. The few that matter for privacy do option 2.

Why browser-side is qualitatively different

The threat model changes completely. With server-side encryption, you're trusting:

• The service to not read your files.
• Their employees to not abuse access.
• Their security team to prevent breaches.
• Their legal team to fight subpoenas.
• Their backup systems to handle keys properly.
• Their decommissioning practices when they shut down or pivot.

That's six layers of trust. With browser-side encryption, you trust your own browser. That's it.

The Web Crypto API makes this practical

For years, "browser encryption" meant a JavaScript library implementing AES from scratch. Slow, hard to audit, prone to side-channel attacks. Today, every modern browser ships the Web Crypto API — native, audited, hardware-accelerated AES exposed to JavaScript via crypto.subtle.

The relevant calls Zippd uses:

• crypto.subtle.generateKey() — produces a real cryptographic key in browser-managed memory.
• crypto.getRandomValues() — fills a buffer with CSPRNG output for IVs.
• crypto.subtle.encrypt() — runs the actual AES-256-GCM operation, hardware-accelerated where available.
• crypto.subtle.decrypt() — same in reverse, with built-in GCM tag verification.

The crypto is implemented by the browser vendor (Mozilla, Google, Apple). They have full-time cryptographers reviewing it. You don't have to trust a npm package — you trust your browser.

How browser-side encryption flows on Zippd

The visible-to-you steps:

1. You drop a file in.
2. The browser generates a random AES-256 key. This happens in milliseconds.
3. The file is sliced into 8 MB chunks. Each chunk is gzipped (when worthwhile) and encrypted with AES-256-GCM.
4. Encrypted chunks PUT in parallel to S3-compatible storage. The server sees only ciphertext.
5. The browser hands you a share URL with the key embedded in the fragment.

You never installed anything. You never gave us your file in plaintext. The crypto happened on your machine.

How to verify browser-side encryption is real

The DevTools test:

1. Open Chrome DevTools (F12).
2. Go to the Network tab.
3. Upload a known file — say a screenshot of a recognizable text.
4. Click on one of the PUT requests in the Network tab.
5. Look at the Request Payload. You should see binary random-looking bytes, not your file's contents.

For Zippd specifically: also check that the request URL goes directly to *.wasabisys.com, not to our backend. Browser → storage, with no plaintext stopover.

Performance: is browser encryption fast enough?

Yes. Modern browsers run AES-256 at 2–4 gigabytes per second thanks to AES-NI hardware instructions. The bottleneck on any real upload is your network, not the encryption. Even a 20 GB file's encryption takes a few seconds of CPU spread across the upload duration.

Compression (when applied) is the slower step, and we auto-skip it for incompressible types like video and images. More on upload performance here.

What about older browsers?

The Web Crypto API has been stable across all major browsers since around 2015. Chrome, Firefox, Safari, Edge — all supported. The only modern context that doesn't ship it is some very locked-down enterprise builds and embedded devices, neither of which are realistic upload sources.

Implications for the threat model

Browser-side encryption changes who can compromise your files:

The threats that browser-side encryption doesn't protect against are the ones at your endpoint. That's unavoidable for any encryption model — at some point the plaintext exists on a device.

FAQ

Can the browser leak my key to the server?

In theory the JavaScript could be modified to send the key home. We don't, and the unminified crypto.js is auditable. Verify yourself in DevTools.

What if my browser is compromised?

Then so is everything else. Encryption is meaningless against malware on the same device that's doing the encryption. Keep your browser updated.

Does this work in Safari?

Yes. All major browsers since around 2015. The Web Crypto API is a W3C standard.

Is the JavaScript audited?

The Web Crypto API itself is implemented by browser vendors and reviewed by their security teams. Zippd's JavaScript that orchestrates it is open for inspection in DevTools.

Watch it happen

Upload a file with DevTools open. The PUT requests will contain ciphertext, not your file.