You drop a file into a "share a link" tool, get a URL back, and send it along. Is it safe to send files with a link? It depends entirely on one question most people never ask: what does the server hosting that link actually have access to? For most link-based transfer tools, the honest answer is "your file, in plaintext, sitting on someone else's storage." Here's what that risk looks like in practice, and what changes when the file is encrypted before it ever leaves your device.
What a typical file-link service actually holds
A conventional "send a file, get a link" service works by uploading your file as-is. The server receives the plaintext bytes, stores them, and hands out a link that lets anyone with the URL fetch them back. That means the provider — and anyone who compromises the provider, or is legally compelled to hand over data, or simply mis-configures a storage bucket — has the same access to your file that you do. The link itself is usually just an opaque ID; it doesn't protect the contents, because nothing about the file was ever hidden from the server that's serving it.
This is the same category of risk covered in is it safe to use online PDF tools: once a file is uploaded to a server you don't control, its confidentiality rests entirely on that server's security practices, retention policy, and legal exposure — not on anything you did.
The one FileX tool that isn't fully local — and why
Every other tool in FileX runs 100% in your browser: nothing is ever uploaded, full stop. FileX Send is the deliberate exception, because a link that works later — potentially from a different device — has to hold the file somewhere in between. Rather than pretend otherwise, FileX documents exactly what that costs you on a dedicated Send threat model page.
The design minimizes what the server ever gets to see:
- Your browser generates a random encryption key locally.
- The file is encrypted with that key — AES-256-GCM, the same authenticated cipher used everywhere else in FileX — before a single byte is uploaded.
- Only the ciphertext goes to the server.
- The key never travels with the upload request. It's appended to the share link after a
#, a URL fragment — a client-side-only part of the URL that browsers never send in an HTTP request. So the server storing your ciphertext never receives the key that unlocks it.
FileX Send's Team tier adds a second layer: an optional password. When set, the actual file key isn't the link key alone — it's derived by combining the link key with the password through HKDF, a standard key-derivation function (RFC 5869), the same construction FileX's hybrid encryption already relies on elsewhere. That means possessing the link alone isn't enough to decrypt a Team file — the password has to reach the recipient through a separate channel, the same "don't send the key with the message" principle covered in how to send a password securely.
What the server can see — and what it can't
Being upfront about this is the point. FileX Send's server side can see:
- The ciphertext bytes and their size.
- A routing ID — an opaque key with no information about the file itself.
- The link's expiry time and how many times it's been downloaded.
- Which pricing tier the sender is on, but only if a license key was attached to the upload.
It can never see: the encryption key, the Team password, the plaintext file contents, or the original filename — which also travels only in the link fragment, never in the request.
Links don't sit around indefinitely, either, and the limits are enforced server-side rather than just suggested by the UI. They vary by tier and do change as the product evolves, so check the Send tool page for current numbers rather than trusting an old post. Free-tier links expire fastest and self-destruct after a single download; paid tiers get longer-lived links with higher size caps and unlimited downloads until expiry; Team links add the password requirement above. Once a link expires or hits its download limit, both the encrypted object and its metadata are deleted.
So — is it safe?
"Safe" depends on what you're protecting against. Encrypting client-side before upload closes off the biggest risk in ordinary link-sharing services: a server operator, or anyone who breaches that server, reading your file. With FileX Send, they'd get ciphertext and nothing to decrypt it with. What client-side encryption doesn't change is availability — the encrypted blob still has to exist somewhere until the recipient downloads it, and its size and rough timing are visible to whoever hosts it. If even that tradeoff isn't one you're willing to make — ciphertext held temporarily, in exchange for a link that works without both people online at once — keeping the file off any server entirely is still an option: encrypt a file to a FileX ID so only one recipient's private key can ever open it, and hand it over however you like.
For most people sharing a document or photo with someone who isn't ready to receive it in the next five minutes, a link where the host only ever holds ciphertext is a meaningfully safer proposition than one where it holds your file in the clear.
Ready to try it? Send a file securely — your file is encrypted before it leaves your browser, and you can read exactly what the server does and doesn't see on the threat model page.