Browser to browser · no upload, ever
Send it straight across.
Every file-sharing service works the same way: your file goes UP to someone’s server, sits there, and comes DOWN. THE COURIER removes the middle. A WebRTC channel pairs your browser with the other person’s and the bytes travel directly between you — encrypted end to end by the channel itself, verified by a SHA-256 computed on both sides as they pass. No account, no upload, no server that could keep a copy, because no server ever has one.
The only thing that travels any other way is the introduction: two short codes you and the other person carry over any channel you already trust — a text message, an email, read aloud on a call. The codes describe the route; they never contain a byte of the file.
Watch it work
The page does it to itself, once, slowly.
The awkward thing about a two-device tool is that nothing happens until there are two devices. So press the button: this page makes a second peer inside this tab, introduces the two through the same codes you would carry by hand, opens a real channel, pushes 256 KB across it and hashes both ends. Nothing is faked and nothing leaves the page — STUN is switched off for the demonstration, so the two peers meet over the loopback interface and nowhere else.
Loopback demonstration
What this proves: the codes, the channel, the chunking and the digest check are all real, and the bytes that arrive are the bytes that left. What it cannot prove is distance — a loopback pair travels no further than this tab. Across two devices the mechanism is identical; the only difference is that a person carries the two codes between them.
Sending
Three steps, one round trip.
This browser does not offer WebRTC data channels (or the compression stream the codes need), so the courier cannot run here. Everything else on this page still reads honestly.
One request goes to a public STUN server, which learns your IP address and nothing else.
The sending desk
1 Choose what to send
Drop files here — or click to choose
They are read in this tab and nowhere else.
2 Create the introduction and carry it to the receiver
The receiver pastes this on their own page, under RECEIVE.
3 Paste the reply they send back
Receiving
Paste, reply, save.
The receiving desk
1 Paste the sender’s introduction
2 Send this reply back to them
The moment they accept it, the channel opens and the files flow.
3 Save what arrived
Method
What travels where, exactly.
The file: browser to browser, and nowhere else
The bytes move over a WebRTC data channel — a direct, DTLS-encrypted pipe between the two browsers. That encryption is not a feature this page added; it is how every data channel works, always, end to end. This site never sees the file, holds no relay for it, and has no TURN server that could carry it — which is also the honest limit: a network that forbids direct pairs (some corporate NATs) simply fails, and the desk says so rather than quietly falling back to a middleman.
Integrity is proved, not promised: a streaming SHA-256 — hand-written, because WebCrypto cannot hash a stream — runs on both sides as the chunks pass, and the receiver’s digest returns as a receipt, so both screens verify the same number. The code self-tests against the published FIPS vectors before it will run.
The introduction: two codes, carried by you
Most WebRTC apps use a signalling server to introduce the
peers — a server this page refuses to have. Instead each
side’s session description is deflate-compressed
into a short code (LC1S. the offer,
LC1R. the reply) that you carry over any
channel you already trust. The codes name candidate
network routes and the channel’s encryption
fingerprint; they contain no file data. Trickle ICE is
off on purpose, so one code each way is the whole
conversation.
One outside host can be involved: a public STUN server, asked once so each browser learns its own outside address. STUN sees your IP and nothing else — no names, no sizes, no bytes. The SAME NETWORK switch removes even that, and then this page contacts nothing at all.