Step 1 Direct, not through a server
Normally your data goes up to a server and back down to the other person — the server sees everything and pays for the bandwidth. WebRTC instead opens a direct path between the two browsers. Lower latency, no server in the data path, and the content is private to the two peers.
Compare the two paths
Step 2 Signaling — introducing the two peers
Two browsers cannot magically know about each other. They need a go-between to swap connection details first. That is signaling: each peer creates a description of how it wants to talk (an SDP offer/answer) and sends it to the other through some channel you provide — typically a small WebSocket server. Once they have each other's details, the server is no longer needed for the media.
Step 3 ICE, STUN & TURN — finding a path through NAT
Most devices sit behind a NAT/router and have no public address, so "connect directly" is not obvious. WebRTC gathers every possible route — called ICE candidates — and tries them until one works. STUN tells a peer its own public address; if a direct path truly cannot be found, TURN relays the traffic as a last resort.
Candidate types, best to worst
ICE tries candidates in order of preference and keeps the first pair that connects. A TURN relay always works but costs bandwidth and adds a hop — so it is the fallback, not the goal.
Step 4 The connection — media tracks & data channels
Once a path is agreed, the peers open a RTCPeerConnection. Over it they can send media tracks (camera/mic, for calls) and data channels (arbitrary bytes, for files/chat/games). Everything is encrypted by default — WebRTC mandates DTLS/SRTP, there is no unencrypted mode.
What rides over the connection
Step 5 How /drop on this site uses it
This is not just theory — it is how two tools here work:
- Signaling only. The server runs a tiny WebSocket relay purely to pass the offer/answer and ICE candidates between the two devices. It never sees your file or text.
- Then it gets out of the way. Once the peers connect, a
RTCDataChannelcarries the bytes directly between the two browsers, encrypted end to end. - TURN is the fallback. On networks too locked-down for a direct path, traffic can relay — but the default and common case is a true peer-to-peer transfer.
That design is why /drop can move a large file between two devices without it ever being uploaded to or stored on the server.
Step 6 Glossary
| Term | In one sentence |
|---|---|
WebRTC | A browser standard for direct peer-to-peer audio, video and data. |
signaling | The out-of-band exchange (e.g. via WebSocket) that introduces two peers. |
SDP | Session Description — the offer/answer describing how a peer wants to connect. |
ICE | The process of gathering and testing candidate paths until one connects. |
STUN | A server that tells a peer its own public address behind NAT. |
TURN | A relay server used only when no direct path can be found. |
RTCDataChannel | A channel for sending arbitrary bytes directly between peers. |
DTLS/SRTP | The mandatory encryption for WebRTC data and media. |
The whole idea: use a server briefly to introduce two peers, find a direct path through NAT with ICE, then send everything peer-to-peer and encrypted. The server's only job is the handshake — after that the two browsers talk straight to each other.