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 network tab
You don’t have to trust this. Open your browser’s developer tools, watch the Network panel, and start a transfer. You’ll see the page’s own static files load, one STUN request, and then peer-to-peer traffic — no upload of your file to any origin server. It’s a property you can observe, not a policy you have to believe.
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.