How FileX Send works — and what we can and can't see
Every other tool in FileX runs entirely in your browser, so the honest answer to "what can you see?" is "nothing." FileX Send is the one exception, and it deserves a straight answer rather than a marketing claim. A link you share has to keep working later, possibly on someone else's device — which means the file has to rest somewhere in between.
This page describes exactly what that costs you. The short version: your file is encrypted in your browser before any upload begins, the decryption key never leaves your device, and we store ciphertext we have no way to read.
The key is never transmitted. It lives in the part of the link after the
# — a URL fragment, which browsers do not send to any server as part of an HTTP
request. We receive the routing ID before the # and nothing after it.
What we cannot see
- Your file's contents. The file is encrypted with AES-256-GCM in your browser before the upload starts. We receive ciphertext only, and we hold no key that opens it.
- The decryption key. Generated in your browser and placed only in the link's URL fragment. It is never part of any request we receive, never in our logs, and never in our storage.
- The original filename. It travels in the same fragment as the key. This is why the encrypted container deliberately does not record the filename in its header — the header reaches our server in clear text alongside the ciphertext, so anything stored there would be visible to us.
- The Team password. On a Team-tier link the decryption key is derived from the link and a password you share separately. We never receive, store, or verify the password — a leaked link alone cannot open the file.
What we do see
Being specific matters more than sounding reassuring. For every transfer we hold:
- The ciphertext and its size. Encrypted bytes we cannot decrypt, plus the byte count, which is inherent to storing a file at all.
- A routing ID. A random UUID used as the storage key. It carries no information about you or the file.
- Expiry and download count. The timestamp the link dies, and how many times it has been fetched, so expiry and download limits can be enforced.
- Your plan tier. Only if you sent a license key — used to decide your size cap and link lifetime, never to identify what you are sending.
- Standard request data. Our host, Cloudflare, processes normal request information such as IP address and browser type to deliver and secure the site. On the free tier we additionally keep a short-lived, per-IP counter to enforce the 3-sends-per-day limit described below.
We do not build a profile from any of this, and there is no account to attach it to — see the privacy policy for how the rest of the site handles data.
Retention policy
Every link has a deadline, set when you upload it and enforced on every download request:
| Tier | Max size | Link expiry | Downloads | Password |
|---|---|---|---|---|
| Free | 10 MB | 24 hours | 1 — self-destructs | — |
| Pro & Lifetime | 250 MB | 7 days | Unlimited until expiry | — |
| Team | 2 GB | 30 days | Unlimited until expiry | Required |
Deletion is not a scheduled sweep that might lag: the moment a link is expired or has been consumed, that request itself triggers removal of both the encrypted object and its metadata record together. A Free-tier link is gone immediately after its single download. Nothing is archived, backed up for recovery, or retained after expiry.
Free-tier senders are also limited to 3 uploads per day per IP address, enforced on our side rather than only in the browser. This exists so Send cannot be turned into a free file-distribution network — it is an abuse control, not a usage meter.
Abuse and takedown
Because we cannot read what is stored, we cannot proactively screen content. What we can do is act on a report: given a link, we can delete the stored object immediately.
To report abuse, email abuse@cybxsan.com with the full
link. Please do not include the part after the # — we do not need it, and sending it
would hand us the decryption key.
FileX is operated by CybXSan from India, and we respond to valid legal process under Indian law. Note what that means in practice: we can produce the ciphertext and the metadata listed above, and nothing else. We cannot decrypt a file, because we have never held the key.
How FileX Send compares
The distinction that matters is not "is it encrypted" — nearly everything is encrypted in transit and at rest. It is who holds the key. If the provider does, then their staff, a breach of their systems, or a legal order can expose your file.
| Service | Encrypted client-side | Server can read content | Max retention | Requires account | Open format |
|---|---|---|---|---|---|
| FileX Send | Yes | No | 30 days (Team) | No | Yes — documented |
| WeTransfer | No | Yes | Varies by plan | Not on free tier | No |
| Bitwarden Send | Yes | No | 31 days | Yes — to send | Yes — open-source |
| Firefox Send | Discontinued by Mozilla in 2020 after sustained malware abuse. Listed because it is still widely recommended — it no longer exists. | ||||
Third-party details reflect each service's publicly documented behaviour and can change without notice — verify against their current documentation before relying on them.
If this trade-off isn't right for you
Sometimes the honest answer is "don't use this tool." If you would rather nothing of yours ever rests on our infrastructure, two fully local alternatives produce a file you can deliver over any channel you already trust:
- Encrypt a file with a password and send the container yourself.
- Encrypt to someone's FileX ID so only their private key can open it — no password to exchange, nothing uploaded.