SendXa / Articles
Privacy
Sending a file privately: who can read what you send
Updated 2026-08-22 · 7 minutes read
Short answer
On the direct route the file is never written to our disk. The server only receives a list of names and sizes; the data stays on the sending machine until the other side hits Download. Everything travels over HTTPS with TLS 1.2 or 1.3, and when the two devices connect directly that path is encrypted with DTLS and never touches our server. When the network blocks a direct connection, the data relays through the server, which sits between the two encrypted ends. For anything that has to be safer than a promise, zip it with a password first and pass the password along some other way.
The real question when sending a file is not whether the service encrypts anything. Nearly all of them say they do. The question is where the file sits, for how long, and who can reach it.
Where the file sits
On the direct route the file does not leave your machine until the other side hits Download. When you drop a file onto the page, what goes to the server is a list of names and sizes. When the other side asks for it, the data flows across and no copy is written to disk.
The server only ever receives the list of names and sizes — just enough to introduce the two sides to each other. The file itself goes straight from one browser to the other; when the network blocks that, it passes through the server without being written to disk.
So there is nothing on our side to read, nothing to leak, and nothing to hand over. Not because we promise not to look, but because no file is sitting there.
How far the encryption goes
- Everything travels over HTTPS with TLS 1.2 or 1.3. The server declares HSTS for a year, and the .app domain ships in the browsers' preload list. Your browser refuses to reach us over plain http in the first place.
- When the two devices connect directly, that path is encrypted with DTLS and the file never passes through our server.
- For the two devices to find each other, each asks a small server what its own public address is. That server is ours, not a public one run by someone else. It sees an IP address, not a file.
What we do not claim
We do not call this end-to-end encrypted. When the network will not let the two devices meet directly, the file relays through the server, and at that point the server sits between the two encrypted ends. We do not read it and we do not log it, but that is an operational promise rather than a mathematical guarantee.
Measured on this service: 56% of transfers by file count go direct, and the rest relay. So the relayed path is not a rare corner case.
For anything that has to be safer than a promise, lock the file before it leaves. The page does not do that for you: zip it with a password using whatever is already on your machine — 7-Zip, WinRAR, or Compress on macOS — then send the archive and pass the password along some other way. What crosses our server is then a block of bytes we cannot open, and none of it rests on a promise.
Zip the file with a password using a tool already on your machine, then send the password by a different channel. What crosses the server is then a block of bytes nobody can open, and that no longer rests on anyone's promise.
How strong the 8-character code is
The code is drawn from an alphabet of 31 letters and digits, so 852 billion possibilities.
- The alphabet drops 0, O, 1, l and i — read a code down the phone and those blur together.
- Case does not matter, so it reads the way it is spoken.
- Codes come from crypto/rand. An ordinary random generator has predictable state, and then the 852 billion on paper means nothing.
A hundred machines guessing flat out would still need thousands of years. Sessions are short-lived on top of that: closing the page ends it, and the code is never handed out again.
Where the share link hides its code
The link the Copy link button produces keeps its code AFTER the hash in the address. Browsers never send the part after the hash to a server. So the code does not reach our access log, does not travel in a Referer header when you click through to another site, and does not sit in any proxy along the way.
The code sits after the hash, and browsers never send that part to a server. So it stays out of access logs, out of the Referer header, and out of every proxy along the way.
The page also strips it out of the address bar as soon as it has read it, so someone looking over your shoulder cannot read it off the screen.
What we know about you
| Item | Stored? |
|---|
| File contents | No, on the direct route |
| File names and sizes | Yes, while the session lives, then gone with it |
| Account, email, your name | None exists, because there is no sign-up |
| IP address | In the server log, like every web server |
| A browser fingerprint to recognise you | No |
No account means no user profile. We have no way to connect two of your visits to each other.
What to actually do
- Ordinary files: just send them. Read out the code, hold up the QR, or send the link.
- Files with other people's data, contracts, ID documents: zip them with a password first, and send the password another way.
- Do not drop a share link into a large group chat and leave it there. Anyone with the link can join the session.
- Close the tab when you are done. The session dies with it and the ID goes back into circulation.
Questions people actually ask
Are files stored on your server?
Not on the direct route. The server only gets a list of names and sizes. The 24-hour leave-it-behind route does store them, and that one you choose deliberately.
Is this end-to-end encrypted?
No, and we do not say it is. When the two devices connect directly, that path is encrypted with DTLS and never touches our server. When the network blocks that, the data relays through the server, which sits between the two encrypted ends.
Can the 8-character code be brute-forced?
852 billion possibilities, from an alphabet of 31 letters and digits. A hundred machines guessing flat out would need thousands of years, and a session only lives a few hours.
So anyone with the link can join?
Yes. The link carries the code, so send it to the right person and keep it out of large groups.
Do you look at my files?
There is nothing to look at on the direct route. On the relayed path the data passes through without being written down.
Do you log IP addresses?
Yes, in the server log like any web server, for abuse control.
What if I need a harder guarantee?
Zip the file with a password using 7-Zip, WinRAR or Compress on macOS, then send the archive and pass the password along some other way. Then the contents do not depend on anyone's promise.
Try it with the file you are stuck on right now
Open the page on both devices, pick the file, read out the 8-character code. Nothing to install, no account, and the file never rests on our server.
Send a file now →