Why "uploading" is the real risk
When you use a normal transfer service, "send" means upload: your file is copied onto a company’s servers, sits there for hours or days, and the recipient downloads a second copy. For that whole window your file lives on a computer you don’t control — subject to their retention policy, their breaches, their subpoenas, and their ads.
The file being encrypted at rest on their end doesn’t remove the copy; it just locks it. The safest copy is the one that never gets made.
How Pairchute avoids the upload entirely
Pairchute opens a direct, encrypted WebRTC connection between the two browsers and streams the file from one disk to the other. There is no upload step because there is no server in the path — nothing to upload to. The only outside contact is a single STUN lookup so the two browsers can find each other’s address; it never sees your file.
Because nothing is stored, a transfer runs in one sitting with both tabs open. That’s the trade for having no server: your file never rests anywhere it shouldn’t.
Verify it yourself in the browser
You don’t have to trust this. Open your browser’s developer tools, watch the Network panel, and run a transfer: you’ll see this page’s own static files load and then nothing further — no request carrying your file to any server, however large the file is. That absence is the whole claim, and it is the one thing the Network panel proves.
The direct connection itself won’t appear there, because WebRTC and its address lookup are UDP rather than HTTP requests. To watch that part, open chrome://webrtc-internals in Chrome or Edge (Firefox: about:webrtc), where you can see the candidate pair that was selected and the data channel carrying the bytes.
Why uploading is also the slower way
Uploading costs you time twice. Home and office connections are asymmetric — a 500/40 Mbit line sends at roughly a twelfth of the rate it receives — and an upload service has to push the entire file up that narrow channel before the recipient can begin pulling it down the wide one. Two hops, in sequence, the first at your slowest speed.
A direct transfer makes one hop. The ceiling is whichever of the two connections is slower, not the sum of two waits. On a shared network it never reaches the internet at all: the bytes cross your router and the drives become the limit.
The gap grows with size. A 20 GB video on a 40 Mbit uplink spends over an hour uploading before a single byte reaches the other person. Over a LAN the same file moves as fast as the two disks can read and write it.
When an upload service is still the right choice
Some jobs need a server, and for those Pairchute is the wrong tool. If the other person can’t be at their computer while you’re at yours, something has to hold the file — and there is nowhere here to hold it. The same applies to a link that must keep working for days, one link sent to twenty people, or a URL you want to paste into a document and forget.
Pairchute is built for the opposite case: one file, two people, both present, nothing left behind afterwards. Working out which case you’re in takes a second, and it saves the annoyance of reaching for a one-sitting tool to do a leave-it-and-forget-it job.
Exactly what crosses the network
The claim is checkable, so here is the whole list. Over HTTP your browser fetches this page with its stylesheet, script and font — the same static files any site serves — and then makes no further HTTP request at all. No upload, no analytics beacon, no cookie, no third-party anything.
Over UDP there is one lookup to a public STUN server, which replies with the address your network presents to the internet so the two browsers can find each other. It never sees your file, and on a shared LAN the local addresses often connect before it is needed. Everything after that rides inside a DTLS-encrypted WebRTC data channel opened directly between the two machines.
The two halves are checked in different places, which is worth knowing before you go looking: the Network panel covers the HTTP half, and chrome://webrtc-internals covers the UDP half. If you ever catch an HTTP request carrying file bytes to a server, something has changed and this page is wrong — which is the point of describing it precisely enough to be falsified.
Send a file now
Scroll up and hit Create invite — you get a link to send the other person. They click it, send one reply back, and the direct encrypted pipe opens. Nothing is uploaded; nothing is stored.
Related
See also: a WeTransfer alternative that never uploads · private, encrypted file transfer — and the Pairchute home page.