How it works

Your file goes straight from one browser to the other. We hand the two of you a code so you can find each other, and then we get out of the way.

The short version. Most “file sharing” sites are upload sites: your file goes to a server, sits in storage, and is handed to the other person from there. This one never receives the file at all. Our server’s entire job lasts a few seconds and involves a six-character code and a small block of connection-setup text.

Step by step

  1. You pick a file. Nothing happens to it yet. It stays on your disk; the page has only been handed a reference to it.
  2. Your browser writes a connection offer. This describes how it can be reached — network addresses, supported settings, and the keys for the encrypted channel. It is a few kilobytes of text, known as an SDP offer. It says nothing about your file.
  3. We store that offer under a random six-character code. This is the only moment our server holds anything at all.
  4. You share the code, link or QR. However you like — a message, out loud across a desk, a camera pointed at the screen.
  5. The other browser fetches the offer and writes an answer. Same shape of thing, going the other way.
  6. The two browsers connect directly and we delete the code. From this point our server is not involved in any way. It could be switched off and the transfer would continue.
  7. The file streams across in small pieces until it is finished, with the receiving side telling the sender to slow down whenever its buffer gets full.

You can check all of this yourself

The connection log on the home page prints every single request we make to our server, as it happens. Run a transfer and watch it: you will see the code created, the handshake exchanged, and then the line saying the code has been deleted. Nothing about your file ever appears, because nothing about your file is ever sent.

If you want harder evidence, open your browser’s developer tools and choose the Network tab before you start. During a large transfer you will see a handful of small requests at the beginning and then nothing, while gigabytes move between the two machines. The bytes going to our domain stay flat.

Once the direct link is up, the page also reads your browser’s own WebRTC statistics and reports the candidate type it negotiated. That reading comes from the browser, not from us.

Is it encrypted?

Yes, and not as an added feature — it is not optional in this design. Browser-to-browser data channels are carried over DTLS, and the browsers negotiate the keys between themselves during the handshake. Even if someone could read the handshake we store, they could not decrypt the transfer, and we could not either. The file is encrypted in transit between the two devices by default, with no setting to turn that off.

What that does not protect against is sending the code to the wrong person. Anyone holding a valid code can connect. Treat it like a key: share it with the person you mean to, and if a transfer never starts, generate a fresh one.

Match words: checking nobody is in the middle

Encryption only helps if each browser is talking to the other one, and not to an impostor. Because the handshake passes through our server, a dishonest or hacked server could in principle hand each side its own fake handshake and quietly sit in the middle of the connection. You shouldn’t have to take our word that it doesn’t, so as soon as the two browsers connect, both screens show the same four match words.

The words are worked out independently by each browser from both sides’ encryption certificates plus random values the two exchange over the encrypted link, which our server never sees. The receiving browser commits to its random value before seeing the sender’s, so anyone in the middle has to choose theirs blind: their chance of making both screens show the same words is about one in four billion. If the words match, the connection is direct. If they don’t, cancel.

By default the transfer starts straight away and you can compare afterwards. For anything sensitive, tick “Let me check the match words before anything is sent” before you create the code: the sending side then waits until you have compared the words (read them out over the phone, or glance at both screens) and pressed the button.

After a dropped connection, each side also checks that it has reconnected to the same device, using the certificate it saw the first time. If a different device answers the code, the transfer stops instead of carrying on.

When each file finishes, both sides also calculate its SHA-256 fingerprint and compare them. A file only shows “✓ verified” once the receiver’s copy matches the sender’s byte for byte, including files that were resumed after a drop.

Both checks rely on your browser’s built-in cryptography, which only runs on a secure (HTTPS) page. If it isn’t available, the page says so instead of showing words.

Why there is no size limit

Limits on other services exist because they are paying to store your file. Nothing is stored here, so there is no quota to enforce. The sending side reads from disk in small pieces as it goes, so the file is never loaded into memory in one lump.

The receiving side gives you a choice:

For something very large in Chrome or Edge, the folder option is still the most direct: the file lands where you chose, with no Save step and no copy.

Installing it, and sharing straight to it

xfrit can be installed like an app: use Install app at the top of the page in Chrome or Edge, or Share → Add to Home Screen on an iPhone. It then opens in its own window and, on Android, appears in the share menu of other apps — share a photo from your gallery to xfrit and it lands in the send list, ready for a code.

That share is caught by a small script running in your browser on your own device, and never goes to our server; if the script isn’t running yet, the server turns the share away without opening it or keeping a copy. The app is the same page as the website: nothing is cached, so it is always the current version.

Asking someone to send you something

Usually the person with the file makes the code. It works the other way round too: on the Receive tab, choose “ask someone to send files to you” and you get a code, link and QR code to give them. They open the link (or enter the code under “Did someone give you a code to send to?” on the Send tab), choose the files, and they come straight to you.

Under the hood nothing changes: your code is an empty placeholder until they answer it with their connection details, and from then on it is an ordinary direct transfer — same encryption, same match words, same resume. Only the first person to use your code can send to it, and cancelling withdraws it straight away. As with any code, only give it to the person you want files from.

Sending a whole folder

Drag a folder onto the page, or use “or choose a whole folder” on a computer. Every file inside it is sent with its place in the folder, and the receiving side rebuilds the same structure:

Folder names come from the sender, so they are cleaned before use: nothing can point outside the folder you chose, and characters your system can’t store in a file name are replaced.

If the connection drops

It recovers on its own. When the direct link breaks — a dead spot, a phone switching between wifi and mobile data, a laptop lid closing briefly — the sending browser republishes a fresh connection offer under the same code. The receiving browser is already watching for exactly that, so the two re-pair without anyone typing anything.

The receiver then tells the sender precisely how many bytes it already holds, and the sender continues from that byte. Nothing that already arrived is sent twice. Both sides keep trying for about two minutes before giving up. Before resuming, each side checks it has reconnected to the same device it started with (more on that).

The one thing that cannot be recovered is closing or reloading a tab. The partly-received data lives in that page, and there is no copy of it anywhere else — not on our server, not in a cache. Leave both tabs open until it says the transfer is complete.

The trade-off we made on purpose

Two browsers can usually find a route to each other. Occasionally a network is locked down hard enough that they cannot — some corporate and school firewalls block direct peer-to-peer connections outright, as a matter of policy.

The standard industry fix is a relay server: when a direct route fails, push the data through a server in the middle instead. We have deliberately not done that. A relay would mean your file passing through our infrastructure, which is the precise thing this site exists not to do. We would rather fail honestly on a minority of networks than quietly become the thing we told you we were not.

So if a transfer refuses to connect, that is almost certainly the reason. Trying from a different network — a phone on mobile data rather than office wifi, for instance — usually works immediately.

The two third parties involved

The website is delivered through Cloudflare, a network in front of our server that keeps it fast and shields it from attacks. The requests your browser makes to this site pass through it, including your IP address and the short connection-setup messages. Your files never do: once the two browsers find each other, the file goes directly between them, with Cloudflare and our server both out of the path.

Before two browsers can reach each other they need to know what their own public address looks like from the outside. That question is answered by a STUN server. We use Google’s public one, at stun.l.google.com:19302 with stun1.l.google.com:19302 as a fallback.

Being precise about what that means: Google sees the networking information attached to that request, including your IP address, exactly as any server you contact does. It does not see your file, your code, or who you are transferring with, and no file data passes through it. Their handling of that request falls under Google’s privacy policy. We mention it because a privacy claim that quietly omits a third party is not worth much.

What our server sees, in full

That is the complete list. There is no account, so no profile and no history. See the privacy page for retention detail.

Browser support

Sending and receiving work in any current browser on desktop or mobile — Chrome, Edge, Firefox, Safari, and the browsers built on them. Two features are narrower: writing straight to a folder needs Chrome or Edge, and the copy button needs a secure connection, which the live site has. Everything else is available everywhere.

Common questions

Can I send to myself? Yes, and it is one of the better uses — phone to laptop without a cable or a cloud account. Open the link on the second device and it fills in the code for you.

Can more than one person receive the same file? Not from a single code; each code pairs exactly two browsers. Generate another code for another recipient.

Does the code expire? Yes. It is deleted as soon as the two sides connect, and in any case within thirty minutes. A code that nobody used simply stops working.

Can you recover a transfer that failed? No, and not because we will not — there is nothing to recover from. Nothing was stored. Start it again.