Zero-Knowledge Encryption

What is Zero Knowledge?

Zero knowledge means that the service provider — filez.zone — has zero knowledge of your file contents. We designed our entire system so that the server never sees the plaintext data you upload, never possesses the encryption keys, and never has the ability to decrypt your files. Even if our servers were compromised, your data remains unreadable.

This is not a marketing claim — it's enforced by cryptography and architecture. The encryption key is generated in your browser, used only in your browser, and embedded in a shareable link in a way that browsers never transmit to web servers. We simply store and serve opaque encrypted blobs we cannot read.

How It Works

Key generation in your browser

When you pick a file to share, a unique 256-bit AES-GCM key is generated directly in your browser using the Web Crypto API. This key never leaves your device in plaintext. A random file identifier (UUID) is also generated to reference the upload.

Client-side encryption

The file is split into 5 MB chunks. Each chunk is encrypted with AES-256-GCM using a random 12-byte initialization vector (IV) per chunk. The output for each chunk is: IV (12 bytes) || ciphertext || GCM tag (16 bytes). All encryption happens locally — the original file never leaves your browser.

Direct upload to storage

Each encrypted chunk is uploaded directly to Cloudflare R2 via presigned URLs generated by our backend. Critically, the file data never passes through our backend servers — it travels straight from your browser to R2. The backend only coordinates the multipart upload flow. It sees upload IDs and part numbers, but never the actual bytes, plaintext or ciphertext.

Key embedded in the URL hash fragment

The encryption key is encoded as URL-safe base64 and appended to the shareable link after a # (hash). For example: /f/uuid#base64key. Hash fragments are never transmitted in HTTP requests — this is a fundamental browser security property. When someone opens the link, the key is extracted locally by JavaScript in their browser. The server never sees it.

Download, decrypt, and burn after reading

When a recipient opens the link, their browser requests the encrypted blob from our backend. The backend fetches it from R2, streams it back, and immediately deletes the object from storage. The recipient's browser then decrypts each chunk using the key from the hash fragment and reassembles the original file. After this single download, the file no longer exists on our infrastructure — burn after reading.

What the Server Can See

It's important to be transparent. While we cannot read your file contents, our infrastructure does process some metadata:

Data	Visible to server?	Explanation
File contents	No	Stored and served as opaque ciphertext. No plaintext access.
Encryption key	No	Lives in URL hash fragment — never sent in HTTP requests.
Original file name	No	Not transmitted to the backend.
File ID (UUID)	~	Generated client-side, used as the storage key. Random, reveals nothing.
Content type (MIME)	Yes	Optional metadata (e.g. "image/png") to help the recipient. Stored alongside the ciphertext.
Upload timestamp & size	Yes	Standard S3 object metadata. Encrypted file size only (slightly larger than original).
IP address	Yes	Logged temporarily for rate limiting and abuse prevention. Not linked to file content.

The key takeaway: everything that could identify or reveal your file's content is either never sent to us (key, file name, plaintext) or encrypted beyond our reach (file contents).

Why the Hash Fragment Matters

The URL hash fragment (the part after #) is special in HTTP: browsers never include it in HTTP requests. This is not something we enforce — it's a fundamental rule of how the web works. When you type a URL with a hash into your browser, or when someone clicks a link with a hash, the fragment stays in the browser's address bar and is accessible to JavaScript, but it is never sent over the network in any HTTP request.

This means the encryption key — which we embed in the hash fragment — is physically impossible for our servers to receive, even if we wanted to. The key exchange happens entirely between the sender and the recipient, mediated only by the URL they share through any channel they choose (messenger, email, QR code, etc.).

Example capability URL:
https://filez.zone/f/a1b2c3d4-e5f6-7890-abcd-ef1234567890#dGhpcyBpcyBhIGtleQ

The browser sends GET /f/a1b2c3d4-... to the server. The part after # is never transmitted. JavaScript extracts it locally to decrypt the file.

End-to-End vs. Zero Knowledge

These terms are related but distinct:

End-to-end encryption (E2EE) means data is encrypted on the sender's device and can only be decrypted on the recipient's device. No intermediary can read it in transit. filez.zone implements this: only the sender and recipient ever hold the key.
Zero knowledge goes a step further: it means the service provider has no technical ability to access the plaintext, even if compelled. This is achieved because we never possess the key at any point — it's generated locally, transmitted only through the hash fragment, and used only in the browser.

filez.zone is both end-to-end encrypted and zero-knowledge. We cannot decrypt your files even if we wanted to or were legally required to.

What This Protects Against

✓ Server breaches

A compromised server yields only encrypted blobs — no keys, no plaintext.

✓ Man-in-the-middle attacks

Keys travel in hash fragments, not over the network. HTTPS protects the ciphertext.

✓ Subpoenas & legal requests

We have nothing to hand over — we don't have the keys or plaintext.

✓ Insider threats

No employee or administrator can access your files. It's cryptographically impossible.

✓ Cloud provider access

Cloudflare R2 stores encrypted data only — they cannot decrypt it.

✓ Accidental leaks

Files auto-delete after first download. Nothing lingers to be exposed later.

Limitations & Responsibilities

Zero knowledge protects your data from us, but it cannot protect against everything. You are responsible for:

Sharing the link securely. Anyone with the capability URL can download the file once. If you share it over an insecure channel and it's intercepted, the interceptor can access the file before the intended recipient.
Verifying the recipient. The burn-after-read model means the first person to open the link gets the file. Make sure you're sharing with the right person.
Your own device security. The encryption key is generated and used in your browser. If your device is compromised (malware, keyloggers, browser extensions), the key could be intercepted before it's embedded in the hash fragment.

These are inherent trade-offs in any zero-knowledge system where the service provider is intentionally kept out of the trust boundary. We believe this is the right trade-off: you control the data, and with that comes the responsibility to handle the link with care.

Technical Verification

You don't have to take our word for it. filez.zone is open source. You can inspect the encryption logic in frontend/src/lib/crypto.ts, the upload flow in frontend/src/lib/upload.ts, and the backend handlers that confirm files are stored and served as opaque binary streams without any decryption capability. The entire codebase is publicly available on GitHub.

You can also verify the behavior directly in your browser's developer tools:

Open the Network tab during upload — you'll see encrypted chunks being PUT directly to R2, never POSTed to our backend.
Inspect the capability URL — the key is in the hash fragment, and the only HTTP request made during download is a GET to the backend with the file ID (no key in the request).
Check the Sources tab for the unminified client-side code — all cryptographic operations are visible and auditable.