Password Protected File Sharing — Done Right

The classic password-protected file share goes like this: you upload a file, set a password, send the link, then send the password through a separate channel. Common practice. Often security theater.

Here's why, and what real password protection looks like.

What "password protection" usually means

On most services, the password is a gate between the share page and the download. The flow:

1. Recipient clicks the link.
2. Page asks for password.
3. Recipient types it.
4. Server checks if it matches.
5. Server serves the file.

Step 4 is the problem. The server has the file. The server compares the password. The server can serve the file to itself, or to anyone it wants to, without the password. The password protects against random outsiders who got the URL. It doesn't protect against the service itself, subpoenas, breaches, or staff with database access.

What real password protection looks like

True password protection means the password is part of the decryption. Without it, the file can't be turned into plaintext — by anyone, including the service hosting it.

This is what end-to-end encryption does naturally. The "password" becomes the encryption key. Without that key, the ciphertext is useless.

How Zippd handles it

Zippd generates a random AES-256 key in your browser, encrypts the file, and embeds the key in the URL fragment. The full share URL looks like:

https://zippd.io/d/QlZc6UjzLA56jBFJ7hxoqg#k=Ms5jHb_xWdQTfYK9oWzL4iX-PnAo7c

The part after # is the encryption key. Browsers never transmit the fragment. The recipient's browser reads the key from the URL bar locally and uses it to decrypt.

That's a 256-bit random key — far stronger than any human-typed password. And it's actually doing the work of decryption, not just gating access.

"But I want my recipient to type something in"

Two reasonable use cases:

• Two-channel verification — you want to send the link in one channel and a code in another, so neither alone is enough.
• UX expectation — your recipient is more comfortable with "type the password" than with "trust me, the key is in the URL."

For two-channel security, you can split the URL yourself. Send the base URL (before #) on one channel. Send the fragment (the k=... part) on another. The recipient pastes them together to access the file. Same security model, two-channel discipline.

A native "extra password" feature is on the roadmap. For now, the URL split is the practical workaround.

Why URL-fragment keys beat type-the-password

Combine password protection with download caps and expiry

Three layers add up:

• Encryption stops anyone without the key.
• Download cap (set to 1) stops link re-use even if forwarded.
• Short expiry shrinks the window for any of the above to fail.

For high-sensitivity sends: encryption + 1-download cap + 24-hour expiry. That's tighter than most "enterprise" file sharing platforms manage.

Comparison with traditional password protection

FAQ

Can I set a custom password instead of the random key?

Not currently in the UI. The random 256-bit key is stronger than any custom password and the only way to maintain zero-knowledge. Custom-password features that work alongside E2EE are on the roadmap.

What if someone gets just the URL but not the fragment?

They get a download page that errors out — no key, no decryption. The ciphertext on storage stays unreadable.

Can I revoke a "password" after sharing?

Sort of. You can delete the file (registered users) or wait for expiry. The key itself can't be revoked — it's the file's identity. Deleting the file makes the key useless.

Are URL fragments really private?

Yes, in HTTPS browser contexts. The fragment is parsed by the browser locally and never transmitted in the HTTP request. Server access logs show only the path, never the fragment.

Try it

Upload a file and look at the share URL. The part after #k= is the only thing standing between the recipient and the plaintext.