"Can’t look", not "won’t look"
A privacy policy is a promise a company can change, breach, or be compelled to break. Pairchute doesn’t rely on one. There is no server that ever holds your file, so there is nothing for anyone — including us — to read, log, hand over, or leak. The privacy comes from the architecture, not from a pledge.
End-to-end encrypted by default
The connection is end-to-end encrypted with keys generated on your two devices, and the transport itself (WebRTC/DTLS) is encrypted on the wire. Every block is hash-verified and the whole file is checked against a root hash before it counts as received, so a corrupted or altered byte cannot pass silently.
Once you are connected, both screens show a matching 6-digit safety code derived from the two device keys and this session’s encryption fingerprints. Comparing it is optional and takes a second — if the two codes differ, someone tampered with the invite on its way over, and you can disconnect before sending anything.
The only outside contact is one STUN lookup
The page loads its own static files and then makes no further HTTP request of any kind — no analytics, no cookies, no account, no trackers, which you can confirm in your browser’s Network panel. Its only other outside contact is a single STUN lookup, sent over UDP, that reports your network’s public address so the two browsers can find each other. It never sees your file. Keep the invite link private, since it carries the connection keys, and nothing else about the transfer ever leaves the two computers.
Nothing left behind
When the transfer finishes and you close the tab, the only trace is the file you saved. There is no account, no stored peer list, no transfer history, and no cookies. The next time you open Pairchute it remembers nothing except this device’s own keypair, which never leaves your machine and exists only to authenticate the encrypted handshake.
What this protects against, and what it does not
A privacy claim without a threat model is marketing, so here is the boundary.
It does protect against a copy of your file existing on someone else’s disk at all — and therefore against retention policies, a breach of a service holding it, a subpoena for a stored copy, an employee reading it, and usage analytics built on what you send. Those risks are removed structurally, not promised away, because the copy is never made.
It does not protect against a computer that is already compromised: malware or someone with access to either machine sees the file the same way you do. It does not vet whoever you send the invite to — hand it to the wrong person and they connect. And it does not hide that a connection happened; anyone observing your network can see traffic between the two addresses, just not what is inside it.
How to check each of these claims yourself
None of this requires taking our word for it, but the checks live in two different places. Open the Network panel and run a transfer: after this page’s own files there should be no further HTTP request, whatever the size of the file. That is what proves nothing is being uploaded.
The connection itself is UDP and so never appears in that panel. For it, open chrome://webrtc-internals in Chrome or Edge (Firefox: about:webrtc): you will find one STUN lookup to Google’s public server at stun.l.google.com, which learns your network’s public address and nothing about your file, then a directly connected candidate pair carrying the data. On a shared LAN even that lookup is often unnecessary, because the local addresses connect first.
Two further checks need no tooling at all. View the page source and you will find no third-party scripts, no tag manager and no tracking pixels — the strict Content-Security-Policy on this page would block them anyway. And once connected, compare the 6-digit safety code on both screens: it is derived from the two device keys and this session’s encryption fingerprints, so matching codes rule out anyone having sat in the middle of the handshake.
The invite link is the secret
Everything above assumes the invite reached the right person, because the invite is what carries the connection keys. Treat it like a password: send it over a channel you already trust, and avoid public posts or forwarded email where it might sit in someone else’s mailbox.
Three properties limit the damage if it leaks. It expires an hour after it is created. It never contains any file data. And the keys live in the part of the URL after the #, which browsers do not send to the server — so pairchute.com itself never receives them even though the link points at pairchute.com.
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: sending without uploading · a private WeTransfer alternative — and the Pairchute home page.