Zero-Knowledge File Sharing Explained in 60 Seconds

← Back to Blog

Zero-knowledge file sharing means the server that stores your file cannot read it. Not "chooses not to" — cannot. It is a technical guarantee, not a policy promise. Here is how it works, step by step.

The Locked Box Analogy

Imagine you want to send a document to a friend through a courier service. You have two options:

Option A (traditional): You hand the document to the courier. The courier puts it in their own locked bag, drives to your friend and hands it over. The courier saw the document. You trusted them not to photocopy it.

Option B (zero-knowledge): You put the document in a locked box that only you have the key to. You give the locked box to the courier. You then text the key to your friend separately. The courier delivers the box but can never open it. Your friend uses the key to unlock it.

Zero-knowledge file sharing is Option B. The "locked box" is AES-256-GCM encryption. The "courier" is the server. The "key texted separately" is the URL fragment.

The Six Steps

Step 1: You Select a File

You pick a file (or multiple files) in your browser. Nothing has been uploaded yet. Everything that follows happens on your device.

Step 2: Your Browser Generates a Random Key

The browser creates a random 256-bit AES encryption key using the Web Crypto API. This key exists only in your browser's memory. It is never sent anywhere.

Step 3: The File Is Encrypted in Your Browser

Using AES-256-GCM (the same encryption standard used by governments and militaries), the browser encrypts the file. The result is a block of random-looking bytes. Without the key, it is indistinguishable from noise.

If you selected multiple files, they are first compressed into a ZIP archive, then the ZIP is encrypted as a single block. The recipient gets all files in one download.

Step 4: The Encrypted Blob Is Uploaded

Only the encrypted data is sent to the server. The server stores it. It does not have the key and cannot decrypt the data. From the server's perspective, it is storing meaningless bytes.

Step 5: The Key Goes into the URL Fragment

This is the clever part. The browser constructs a URL like:

https://example.com/#/receive?id=abc123&k=THE_KEY_HERE

Everything after the # is called the "fragment." Here is the critical rule: browsers never send the fragment to the server. This is not a feature of any particular application — it is how HTTP works, defined in RFC 3986. When your browser requests a URL, it sends everything before the # to the server and keeps the fragment for itself.

This is not security by obscurity. The fact that fragments are never sent to servers is a fundamental, well-tested property of the HTTP protocol. Every browser implements this. It is the same mechanism that makes anchor links (#section) work on web pages without triggering a new server request.

Step 6: The Recipient Opens the Link

When the recipient opens the URL, their browser reads the fragment (including the key), downloads the encrypted blob from the server and decrypts it locally. The decrypted file appears in their browser. The server was involved in delivering the encrypted data but never had access to the key or the plaintext.

What the Server Knows (And Doesn't)

The server knows	The server does NOT know
That someone uploaded encrypted data	What the file contains
The size of the encrypted blob	The file name
When it was uploaded	The file type
When it was downloaded	The decryption key
The sender's IP address	Who the recipient is (no account needed)

Why This Matters

With zero-knowledge architecture, three categories of risk disappear:

Server breaches. If an attacker compromises the server, they get encrypted blobs they cannot read. The keys were never stored there.
Insider threats. Server administrators cannot access your files. There is nothing to access — only ciphertext.
Legal compulsion. If a government demands user data, the server operator can only provide encrypted bytes. No key means no decryption.

Optional Protections on Top

SecureSend in UnveilPass adds several layers beyond the core zero-knowledge mechanism:

TTL (Time to Live). Choose how long the encrypted data stays on the server: 15 minutes, 1 hour, 3 hours, 6 hours, 12 hours, 24 hours or 7 days. After expiration, the encrypted data is permanently deleted.
Single-use download. The encrypted data is deleted immediately after the first download. The link becomes useless.
Download counter. See how many times the link has been used, so you know if someone else accessed it.
Encrypted message. Attach an optional message that is encrypted alongside the file. The server cannot read the message either.

Sixty Seconds, Summarized

Your browser encrypts the file. The server stores encrypted bytes it cannot read. The decryption key travels in the URL fragment, which is never sent to the server. The recipient's browser decrypts the file locally. Nobody in between — not the server, not the network, not a government — can read your file. That is zero-knowledge file sharing.

Try SecureSend — Free Encrypted File Sharing

Send files with end-to-end encryption. The server never sees your data. No account required to receive.

Get Started Free