What “zero-knowledge” means (in practice)
In everyday terms, —zero-knowledge file sharing— means the service hosting the bytes can't actually read the file content.
That happens when encryption is performed client-side (in your browser) before upload, and the decryption key is kept
out of server storage and logs.
With FileShot, recipients decrypt locally in the browser. The server's job is to store encrypted blobs and deliver them back.
If someone compromises the server storage, they should only obtain ciphertext.
How the flow works (plain English)
When you upload a file, your browser generates (or derives) a key and encrypts the file before any data is sent over the network.
The upload contains encrypted bytes plus the information needed to decrypt later (like salts/IVs), but not the secret key itself.
When someone opens the share link, the download page fetches the encrypted bytes from the server and decrypts them locally after it
obtains the key (either from a password they type or from the URL fragment).
Password links vs fragment-only key links
FileShot supports two UX paths that keep encryption always-on:
Password ON
The encryption key is derived from your passphrase using Argon2id (memory-hard KDF). Recipients must enter the same password to decrypt.
This is the “classic” model: you share a link and separately share a password.
Password OFF
A random key is generated and stored only in the URL fragment (e.g. #k=...). Browsers do not send fragments
in HTTP requests, so the server never receives the decryption key. For recipients, the page can auto-unlock because the key is already local.
Why the URL fragment matters
The fragment (everything after #) is handled entirely client-side. It does not go to:
server request logs, analytics beacons tied to request URLs, or intermediaries that only see HTTP requests.
This is one of the simplest practical ways to keep —the secret— off the server.
The tradeoff is usability: if someone copies a link incorrectly (some apps strip fragments), the recipient won't have the key.
FileShot keeps password mode available for scenarios where “link compatibility” is more important.
What the server can still see
Zero-knowledge encryption protects file contents, not everything about the transfer. Depending on the feature set you're using,
the server may still learn metadata such as file size, upload time, and the fact that a given file ID exists and was downloaded.
If your threat model includes —I don't want the server to learn anything at all,— you're usually in self-hosting / private storage territory.
FileShot's goal is to dramatically reduce what the server can access from stored bytes.
Threat model (being honest)
Zero-knowledge encryption reduces what the server can learn from stored file bytes. It does not magically protect against every threat:
delivered JavaScript integrity, compromised devices, and browser extensions can still matter.
Practical tips (that actually help)
If you're sharing something sensitive, treat the link as a capability. Anyone who has the key can decrypt.
For password links, avoid sending the password in the same channel as the link. For fragment-key links, prefer copying from the app's “Copy link”
button and test that your messaging app doesn't strip fragments.
Also: if you lose the key/password, the file is unrecoverable by design. That's what “zero-knowledge” buys you.
