A peer-to-peer file transfer sounds simple: your browser talks directly to the other person’s browser, and the file travels between them with nothing in the middle. In practice, getting two browsers to reach each other directly is the hard part, because most devices on the internet are not directly reachable at all.
The reason is a technology called NAT, or Network Address Translation. Your home router has one public IP address that it shares among every device on your network — your laptop, your phone, your TV. Inside the network each device has a private address that means nothing to the outside world. When your laptop opens a website, the router rewrites the outgoing packets so the reply comes back to the right device. This works beautifully for connections you start, but it means nobody on the outside can simply open a connection to your laptop, because from the internet’s point of view your laptop has no address of its own.
For a P2P transfer, both sides face this problem at the same time. Each browser sits behind its own router, and neither one can see the other’s real address. So before any file can move, the two browsers have to discover a path to each other. This discovery process is handled by a framework built into WebRTC called ICE, short for Interactive Connectivity Establishment.
ICE works by gathering every possible way a browser might be reached, called candidates, and then testing them until one pair works. The first candidate is the browser’s local network address, which is enough when both people are on the same Wi-Fi. To learn its public address, the browser asks a STUN server — a tiny, cheap service whose only job is to reply, in effect, ‘the address I see you coming from is this one.’ Armed with that public address, each browser shares its candidates with the other through the signaling server, and ICE tries to punch a direct hole through both routers.
For a large majority of connections, this succeeds and you get a true direct link: the file flows from one device straight to the other at the full speed the network allows, and the signaling server drops out of the picture entirely. But some networks are stubborn. Corporate firewalls, carrier-grade NAT on mobile networks, and certain symmetric NAT configurations rewrite addresses in ways that make hole-punching impossible. When ICE exhausts every direct candidate and none of them connect, it needs a fallback. That fallback is TURN.
A TURN server, short for Traversal Using Relays around NAT, is a relay that both browsers can reach because it has a stable public address that anyone can connect to. Instead of talking to each other directly, both browsers connect outward to the TURN server, and it forwards packets between them. Since each side is making an outbound connection — the kind NAT always allows — the relay sidesteps the reachability problem entirely. The transfer is a little slower and it uses the relay operator’s bandwidth, which is why it is only used when a direct path genuinely cannot be built.
Here is the part that matters most for privacy: routing your data through a relay does not expose it. WebRTC encrypts every DataChannel with DTLS, and that encryption is negotiated end to end between the two browsers, using keys that never leave them. The TURN relay only ever sees encrypted packets. It forwards ciphertext it cannot read, has no key to decrypt it, and keeps nothing. From a security standpoint a relayed transfer is just as private as a direct one — the only thing that changes is the network path the encrypted bytes travel.
BigFileDrop uses exactly this layered approach, and it happens automatically. When you start a transfer, ICE first tries for a direct connection using your local and STUN-discovered addresses. If that works, great — you get the fastest possible path. If your network blocks it, the transfer quietly falls back to the TURN relay so the file still gets through instead of failing outright. You do not have to configure anything or even know which path was used.
For very large files there is an additional option: a temporary store-and-forward relay. Rather than requiring both people to be online at the same instant for every byte, encrypted data can be briefly held by the relay and passed along. Even here the data stays encrypted and nothing is kept permanently — the relay is a pass-through buffer, not storage. The moment the transfer completes, there is nothing left behind.
The practical takeaway is that you do not need to understand NAT or ICE to send a file, but it helps to know why a transfer occasionally routes through a relay and why that is nothing to worry about. Direct is faster, relayed is more resilient, and both are encrypted end to end. The system simply picks whichever one will actually get your file where it needs to go.