How WebRTC peer-to-peer file transfer works

You pick a file, hit send, and another device — across the room or across the world — receives it instantly. No upload progress bar, no 2 GB cap, no "your file is too big" error. That is the promise of WebRTC peer-to-peer file transfer. This post explains exactly how it happens under the hood.

The short version: two browsers exchange tiny signaling messages through a server, discover each other's real address with STUN, then open a direct, encrypted data channel. From that moment on, your file bytes flow straight between the two devices.

What is WebRTC?

WebRTC (Web Real-Time Communication) is a browser standard that enables real-time, peer-to-peer communication. It powers voice and video calls in browsers, but its data channel API is what makes file transfer possible. A data channel is a reliable, ordered message pipe between two browsers — think of it as a WebSocket that skips the middleman.

Because the connection is direct, the file you send never lands on a relay server. That removes the classic cloud bottlenecks: upload caps, storage quotas, and your data sitting on someone else's disk. The trade-off is in how the two peers find each other — which is the interesting part.

How two browsers find each other

Signaling: gossip before the handshake

Two browsers have no idea where each other is on the internet. Before anything happens, they need to exchange connection metadata: session description offers and answers, and ICE candidates. WebRTC deliberately does not define how this exchange happens, so apps build a tiny signaling channel — most commonly over WebSockets or, as in ShareFile, via a realtime database table. Our signaling setup passes offers and answers between peers, then steps out of the way.

Crucially, signaling data contains metadata — addresses and session descriptions — never file content. The room code you share is just the lookup key for that metadata exchange.

STUN and NAT traversal

Almost every device sits behind a router doing network address translation (NAT). Your public IP is really your router's IP, and the router decides which incoming packets belong to your device. A STUN server answers one question: "what does the outside world see as my address?" The browser then tries direct connections to that discovered address from every network interface it has — a process called ICE (Interactive Connectivity Establishment).

TURN: when direct isn't possible

Some strict corporate firewalls and symmetric NAT configurations refuse direct connections entirely. In that case a TURN server relays the stream between peers. The file still doesn't get stored anywhere — TURN just forwards packets — but your traffic does pass through it, which is why priority TURN access is a paid upgrade rather than a core part of the free P2P promise. When a direct path works, a peer-to-peer connection never touches a TURN relay at all.

The data channel at work

DTLS encryption and SCTP messages

Once the peers agree on a transport, every data channel message is encrypted with DTLS — Datagram Transport Layer Security. That is the same TLS handshake your browser uses on HTTPS, adapted for UDP. On top of it rides SCTP, which gives the channel reliable, ordered delivery. The combination is why a WebRTC transfer can fairly be called end-to-end encrypted: only the two peers hold the keys.

Creating the connection looks like this in the browser:

const pc = new RTCPeerConnection({ iceServers: [
  { urls: "stun:stun.l.google.com:19302" },
] });

const channel = pc.createDataChannel("files", {
  ordered: true,
});

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// send offer to peer via signaling channel
// peer replies with an answer, then ICE candidates flow both ways

pc.ondatachannel = (event) => {
  event.channel.onmessage = ({ data }) => {
    console.log("Received chunk:", data.byteLength, "bytes");
  };
};

Chunking the file

A 4 GB video can't be shoved into one SCTP message. Senders slice files into small chunks — a few kilobytes each — and stream them over the data channel while the receiver reassembles them in order and writes them back to disk. ShareFile shows live progress and speed on both ends so you know the transfer is actually flowing, not just buffered.

Common problems and troubleshooting

• Connection fails on symmetric NAT: direct paths are refused, so a TURN relay is required. On free tiers this can block the transfer — try switching networks or retry later.
• Slow transfer on Wi-Fi: WebRTC only runs as fast as your slowest link. Move closer to the router or use a wired connection for huge files.
• Large file fills memory: transfers over a few gigabytes hold chunks in memory. Keep an eye on the progress bar and close other tabs.
• Both peers offline: P2P needs both devices online at the same time. That is exactly the case where cloud storage shines instead.

FAQ

Questions about P2P file transfer come up all the time. The short answers: direct transfers need no file storage, work on almost any network, and the file never lives on a server. For the deeper details, check the related articles below.