Every file you upload to a website passes through a machine you do not control, and most of the time that is fine. For a PDF you would rather not hand to a stranger's server, there is an alternative that has been available in browsers for years: send it directly, browser to browser, with nothing stored in between.
The basic idea
Two browsers open a connection to each other and one writes bytes into it while the other reads them. The file never lands on a server. The server's only job is to introduce the two peers — to help them find each other — and once that handshake is done, it can be out of the picture entirely.
The technology is WebRTC. It is the same stack that carries video calls, and its data channel mode is a general-purpose, ordered, reliable transport that happens to be well suited to moving a file.
How the introduction works
Two machines behind home routers cannot address each other directly; neither knows the other's public address, and both are behind NAT. So the process starts with signalling:
- Each peer connects to a signalling server and registers.
- The two peers exchange connection descriptions — session descriptions and ICE candidates, which are candidate network paths.
- Both sides try the paths they learned, including direct ones via STUN, and a relay via TURN when a direct path cannot be established.
Once a path is negotiated, the data flows peer to peer. If a direct path works, the file genuinely never touches a server. If it does not, TURN relays it — and that is the caveat worth knowing: a relay is a server, and in that configuration your bytes do pass through one, encrypted but not end-to-end hidden from the operator.
Why this beats uploading
- Nothing to retain. There is no stored copy, no bucket, no retention policy, no backup, and no breach surface on the server side. The best way to protect a file is for the service to never have it.
- No size limits worth naming. Upload limits exist because storage costs money. A direct transfer is bounded by your connection and patience, not by an API quota.
- Speed when both sides are on good links. No round trip through a datacentre; if both peers are on the same network, the transfer is limited by the local link.
The limits, stated plainly
- Both parties must be online at the same time. This is the real cost. An upload works when the recipient is asleep; a direct transfer does not.
- NAT and firewalls sometimes win. A small fraction of network pairs need TURN relaying, which reintroduces a server and slows things down.
- No resumable transfer for free. Doing it properly means chunking the file, tracking progress, and handling reconnects — real engineering, and why most services just use object storage.
- The introduction server is still a service. It learns who connected to whom and when, even if it never sees the file. Metadata is not nothing.
- Browser support is good but the handshake is fiddly. Chrome, Firefox, Safari, and Edge all support data channels, but the ICE and signalling dance has many failure modes that only show up on real networks.
Where this belongs
Direct transfer is the right tool when the file is sensitive and both people are present — sending a contract to a colleague, moving a file between your own laptop and phone, handing a photo to someone in the same room. It is the wrong tool for asynchronous delivery, for a client who will download it next Tuesday, or when you need a durable copy.
Before uploading anything, it is worth asking whether the file needs to be stored at all. Often it only needs to arrive.
No comments yet