WebRTC, Relays, and P2P: How Files Actually Move Between Browsers

When you send a file from one browser to another, it feels like a single action: drag, drop, wait, done. Underneath, there are really only three architectures doing the work, and they behave very differently in terms of speed, privacy, and what happens when networks misbehave. Knowing which one a given tool uses tells you most of what you need to know about its trade-offs.

This is a neutral primer on those three models — cloud upload-then-download, server relay, and peer-to-peer over WebRTC — and an honest look at the networking reality that makes "peer-to-peer" a leakier label than most people assume. The goal is that you can read a service's description and reason about what you are actually getting, rather than taking a marketing word at face value.

Model 1: Cloud upload-then-download (store-and-forward)

This is the classic model behind email attachments, generic share links, and services like WeTransfer or Dropbox. The sender's browser uploads the entire file to a server, the server writes it to disk or object storage, and later the recipient downloads it from that server. The two people never talk to each other directly; the server is a durable middle box that holds the bytes in between.

What it's good at

The two parties never need to be online at the same time. You upload now; the recipient downloads tomorrow. It tolerates flaky connections well because each half — upload and download — is an independent, resumable transfer against a stable endpoint. It also scales easily to many recipients: one upload, many downloads.

The cost

The file physically sits on someone else's disk, often for days, sometimes longer than you would guess. That storage window is usually the single largest privacy and compliance exposure in everyday file sharing: it is the thing that can be subpoenaed, breached, backed up, indexed, or simply forgotten about. Unless you encrypted the file yourself before upload — for example with age, gpg, or a password-protected archive — the provider can technically read the bytes at rest, even when the upload itself happened over TLS.

Model 2: Server relay / tunnel

A relay forwards bytes in real time. The sender streams the file to a server, and the server immediately streams those bytes to the recipient as they arrive, while both sides are connected. Think of it as a pipe rather than a warehouse. Most relays buffer briefly in memory to smooth out network jitter; a strict "no-storage" relay never writes the file to disk and holds only the chunks currently in flight.

Where it sits between the other two

A relay still has a server in the middle, so it works through almost any firewall and NAT — outbound HTTPS to a known host is the most universally allowed traffic on the internet. But because nothing is persisted, it removes the long-lived-file risk that defines Model 1. The trade-off is that both parties must be online at roughly the same time, because there is no warehouse holding the file for later pickup.

What the relay can and can't see

During the transfer, the relay process holds chunks in memory in order to forward them, so a malicious or compromised operator could in principle observe plaintext bytes in flight — unless the payload is end-to-end encrypted before it leaves the sender. The relay also always sees metadata: file name, size, timing, and the IP addresses of both ends. After the transfer, a no-storage relay has nothing left on disk to hand over, though logs may still record metadata. This no-storage relay pattern is used by a number of self-hostable tools and tunneling utilities, including File Tunnel.

Model 3: Peer-to-peer via WebRTC

WebRTC is the browser standard that lets two browsers open a direct connection to each other and move data over an RTCDataChannel without the bytes passing through an application server. In the ideal case, the file goes straight from the sender's machine to the receiver's machine — lowest latency, no application middle box reading the payload.

You still need a server to start

This is the first thing people miss: even "serverless" P2P needs a small server for signaling. The two browsers cannot find each other from nothing — they must first exchange connection details (the WebRTC offer/answer SDP and ICE candidates) through some shared channel. That signaling server sees who is connecting to whom, and when, but not the file itself. After signaling completes, the data path can be direct — in theory.

The networking reality: NAT, STUN, and TURN

Here is the part that gets glossed over. Almost no consumer device has a public IP address it can be reached on directly. Your laptop sits behind a home router, a corporate firewall, or a mobile carrier's NAT (Network Address Translation), which rewrites addresses so many devices can share one public IP. Two browsers, each behind their own NAT, cannot simply send packets to each other — neither knows the other's reachable address, and the NATs drop unsolicited inbound packets.

STUN: discovering your own address

A STUN server solves the first half. A browser asks a public STUN server "what does my address look like from the outside?" and gets back the public IP and port the NAT is currently mapping it to. Both peers do this, swap the results via signaling as part of ICE, and then attempt to send packets directly — a process called hole-punching. STUN is lightweight and stateless; it only helps the peers learn addresses, and it never carries the file.

TURN: relaying when hole-punching fails

Hole-punching does not always work. Symmetric NATs, strict corporate firewalls, and some carrier-grade NATs assign unpredictable ports or block direct peer traffic outright, often by blocking UDP entirely. When the peers cannot establish a direct path, WebRTC falls back through ICE to a TURN server, which relays the data between them. This is the crucial honest point: a TURN relay is, functionally, Model 2 again — a server forwarding your bytes. Your "peer-to-peer" transfer silently became a relayed transfer, and the application rarely surfaces that it happened.

How often does P2P actually stay P2P?

Published WebRTC telemetry consistently puts the TURN fallback rate around 15–20% for general consumer populations — meaning direct connections succeed roughly four times out of five. But that average hides huge variance. On managed enterprise networks where firewalls block UDP, measured relay rates of 50–70% are common, and some carrier-grade-NAT or IoT environments need TURN essentially all the time. Mobile networks land somewhere in between. So "P2P" in practice means "direct most of the time on a typical home network, relayed a meaningful and sometimes dominant fraction of the time elsewhere" — and the app usually does not tell the user which one happened on a given transfer. If your mental model is "the bytes never touch a server," treat that as a likely default, not a guarantee.

Trade-offs side by side

Each model wins on different axes. None dominates the others.

• Reliability: Cloud upload is the most forgiving — independent resumable halves, no need for simultaneous presence. Relay needs both parties online but is robust through firewalls. Raw P2P is the least reliable to establish, which is exactly why WebRTC builds in the TURN fallback.
• Speed: Direct P2P on a good local network can be the fastest and lowest-latency, with no server round trip. But across the internet, a well-placed relay can beat a P2P path that is forced over a distant TURN server or squeezed through a congested home uplink. "P2P is always faster" is a myth.
• Privacy / threat model: True P2P keeps the payload off any application server, though signaling still sees metadata. A no-storage relay sees bytes only in memory, briefly. A cloud upload stores bytes at rest — typically the largest exposure. Payload-level end-to-end encryption changes this picture for relay and cloud alike by making the server's view useless.
• Both online at once: Required for relay and P2P. Not required for cloud upload — its defining advantage.
• Firewall behavior: Cloud and relay use ordinary outbound HTTPS and work almost everywhere. P2P depends on UDP hole-punching that restrictive networks block, forcing the TURN fallback (which itself rides ordinary connections).

What you need maps to a model

When none of this applies

It is worth being clear about where this framing stops being useful. If both people are on the same local network, the cleanest answer is often none of the three: a shared folder, AirDrop-style OS transfer, or copying to a USB stick avoids the internet entirely and sidesteps every concern above. If you are moving files between two machines you both control, a direct scp/rsync over SSH or a synced drive is simpler and more auditable than any browser model. And if the file is enormous and the recipient is offline indefinitely, physically shipping a drive can still beat any upload — bandwidth has limits that a courier does not.

None of the three models protects you from a compromised endpoint. If the sender's or receiver's machine has malware, the file is exposed regardless of how it traveled. No transfer architecture fixes a bad recipient either — if you should not be trusting them with the file, the protocol cannot help.

None of them automatically gives you end-to-end encryption of the payload, either. WebRTC data channels are always encrypted in transit with DTLS, and relays and cloud services use TLS (1.3 by default in 2026, with forward secrecy), but "encrypted in transit" is not the same as "the server literally cannot read it." Each server you talk to terminates its own TLS or DTLS session and sees plaintext on the inside. Only payload-level encryption that you control — encrypting the file before it leaves your browser — guarantees that the middle box, including a TURN server, only ever sees ciphertext.

And metadata leaks in every model. Signaling servers, relays, and cloud backends all observe who connected to whom, when, file sizes, and IP addresses. If even that is sensitive, you need a self-hosted component or an anonymizing network, not just a choice among these three.

The honest close

There is no best model — there is a best model for a given need. If the recipient is not online, cloud upload is the only real option among the three, and the storage window is the price. If you want nothing left stored and both people are present, a relay or P2P fits. If you want the bytes to avoid an application server's disk entirely, WebRTC P2P is the right intent — just understand that it falls back to a relay a meaningful fraction of the time, that the fraction can be most of the time on restrictive networks, and that direct is not automatically faster across the internet.

The most useful habit is to stop reading words like "peer-to-peer" or "secure" as absolutes, and instead ask the mechanical questions: Does a server store the file? Does a server see the bytes in memory? Do both parties need to be online? What does the fallback do, and how often does it fire on networks like mine? Once you can answer those, you can evaluate any tool — named in this article or not — on its actual behavior rather than its branding.