← Back to sending files

Security commitments — SendXa

SendXa moves files from one device to another without turning them into data that sits on our server. No account, and nothing collected beyond what it takes to join the two devices. This page sets out what we do, what we do not do, and where you can check for yourself.

Last updated: 22 August 2026

• No account needed. No sign-up, no password, no user profile.
• Nothing is stored on the direct route. Only the 24-hour route writes to disk, and you have to choose it.
• Nothing touches your machine. No install, no remote control, no view of your screen.
• Only the files you pick. Nothing else on your disk is readable to us.
• Every route is encrypted. When the network allows it, the two devices connect directly.
• No ads, no tracking code, and no data sold to anyone.

Files never rest on our server

The receiver hits download, the server joins the two ends and pushes bytes across. Nothing is written to disk. In the device-to-device flow the server has nowhere to put a file at all. What it does hold is the minimum needed for the two sides to meet: file names, sizes and a few technical details of the connection. Those live in memory and go when the session does. It also means you never wait through two transfers, and there is no leftover copy to delete later.

The 24-hour route, and how it differs

There is a separate route for when the other machine is not online: the files are written to our disk and you get a link. It is the one exception to the section above, so here it is in plain words. On this route anyone with the link can download, with no ID and no code. The files delete themselves after 24 hours, up to 500 MB each. There is a log recording file name, size, timestamp and the uploader's IP address, so abuse can be traced. This never happens on its own: you have to pick it, and the page asks again before it does anything.

Locking a file with your own password

Next to the file picker there is a lock option, off by default. Turn it on and the file is encrypted with AES-256 on your own machine before it leaves. The key is derived from your password with PBKDF2 at 250,000 rounds. The password never leaves your browser: not to our server, not into the link, not stored anywhere. The original filename is inside the encrypted part too, so our server only ever sees a random name. This is how you turn the operational promise at the bottom of this page into a mathematical guarantee. The trade: forget the password and it is gone for good, and this route is capped at 100 MB per file.

Only the files you pick

SendXa runs in your browser and can only read files you drag in or choose yourself. Browsers do not let a web page read anywhere else on your disk: no browsing folders, no reaching into your photos or documents, nothing beyond what you hand over. We ask for no extra permission either. The same goes for the other end: the receiver can only download files listed in that one send.

We do not control your computer

SendXa is a web page, not software installed on your machine. It cannot see your screen, move your mouse or keyboard, open other folders, or run commands. Remote control is a separate product that you would have to install on purpose. None of it is in this page.

Who can join your send

Every send has a 6-digit ID and a 4-digit code, and you need both to see the file list. Five wrong guesses from one machine, or twenty across several, and it locks for good. When locked the server answers "session not found" rather than "locked", because the second answer would confirm the ID is real.

What someone in the session can do

A session is shared ground for the people inside it. Anyone who joins can also put files or text into the list, so read the 4-digit code only to the person you mean to exchange with. Every row records who added it, and whoever added a row can remove it. The person who opened the session holds a separate credential the others never receive: only they can remove any row and close the whole session, and nobody can impersonate them.

The session lives in your tab

Your browser keeps the ID, code and ticket in storage belonging to that one tab, so a reload or an accidental close still puts you back in. It is not a cookie: it does not ride along with every request to the network, and it does not reach other tabs. Close the tab for good and it is gone, and your ticket does not work from another device.

The connection is always encrypted

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, so there is no downgrade to attempt. 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 and nothing more. No file, no idea who you are sending to. We run it ourselves rather than hand your address to a third party just to save the effort.

What we do not promise

We do not claim SendXa is airtight in every situation. When the network will not let the two devices meet directly, the file passes through our server. There the server sits between the two encrypted ends. We do not read it and we do not record it, but that is an operational promise, not a mathematical guarantee. We would rather say so than let you assume otherwise. If your file needs more than a promise, turn on Lock with my own password next to the file picker. What crosses our server is then a block of bytes we cannot open, and none of it rests on any promise any more. Send the password to the other person by some other channel.

Information about the two devices

We collect nothing that identifies your machine: no hardware fingerprint, no tracking pixel, no user profile. Operational logs hold IP addresses, timestamps, the number of files in a send, and error details when something breaks. That is enough to find the cause of a fault and block abuse, and we do not use it for anything else. For the direct route they contain no file names and no file contents; the 24-hour route keeps its own log, and that one does record file names.

No third-party code here

This page loads nothing from any other server: no ad network, no analytics, no external libraries, no external fonts. No third party learns that you opened it. The content security policy blocks every outbound connection, so even if someone injected foreign code into the page, that code would have nowhere to send anything.

Sends expire on their own

A send lasts at most 12 hours, after which the ID and code stop working whether the transfer finished or not. Close it sooner and everything about it disappears at that moment: file names, sizes, code, credentials, all of it. To keep sharing, open a new session.

In short

A file transfer service does its job properly only if it does not keep your files. We handle the minimum it takes to join two devices, and drop it when the session closes. The file stays yours. Our part is getting it to the other device and nothing more.

Questions, or a hole to report

If anything here looks wrong, incomplete, or at odds with what the service actually does, say so plainly. We read everything. If you find a security flaw, please tell us before publishing and give us reasonable time to fix it. We do not pursue good-faith researchers. We usually reply within a business day or two.

Open the contact pageor write straight to info@macxa.app