Part 1 let the server reach the browser; Part 2 gave the browser an equal voice back. But in both, every byte still travels through a server. This final part is about the one browser technology that removes the server from the middle: WebRTC, which lets one browser talk straight to another — video, audio, and data, peer to peer.
This reflects the state of the web platform as of 2026. WebRTC is mature and widely supported, but the surrounding infrastructure (STUN/TURN servers, signaling) is yours to run — verify current API details on MDN before building.
Beyond HTTP is a three-part series. Part 1 — server push. Part 2 — two-way channels. Part 3 — browser to browser (you are here).
The mental model: cut out the middleman
WebRTC (Web Real-Time Communication) lets two browsers exchange media and data directly, without routing every byte through a server. Recall the arc so far: one-way push, then two-way client-to-server channels. WebRTC is the leap to a different topology — peer-to-peer (P2P), where the two endpoints are two users' browsers and the connection between them is as direct as the network allows.
Why bother removing the server? Latency and cost. A video call relayed through a data center adds a detour and a bandwidth bill for every minute of video; a direct path is shorter and cheaper. But "let two browsers on two home networks find and connect to each other directly" turns out to be one of the harder problems on the web, and most of WebRTC's complexity is spent solving it. The rest of this post is that problem, in three pieces: what WebRTC carries, how the two peers first find each other, and how they punch a hole through the network to connect.
What WebRTC carries
A single WebRTC connection can carry live media and arbitrary application data, over two purpose-built channels. The whole thing is orchestrated by one object, RTCPeerConnection:
- Media tracks — camera and microphone captured via
getUserMedia(), sent over the Secure Real-time Transport Protocol (SRTP). This path is tuned for audio and video: it tolerates a little loss to stay low-latency, because a dropped frame matters less than a late one. - Data channels — arbitrary bytes via
RTCDataChannel, running over the Stream Control Transmission Protocol (SCTP) tunneled inside Datagram Transport Layer Security (DTLS) over UDP. A data channel can be configured reliable-and-ordered (like a WebSocket) or unreliable (like a WebTransport datagram) — your choice per channel.
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.example.com:3478' }],
});
// Live media:
const media = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
media.getTracks().forEach((track) => pc.addTrack(track, media));
// Arbitrary data, peer to peer:
const chat = pc.createDataChannel('chat');
chat.onmessage = (event) => render(event.data);
That covers what flows. The harder question is how the two peers ever reach each other in the first place.
The signaling gap: WebRTC brings no phone book
WebRTC deliberately defines no way for two peers to find each other — you must carry their introduction yourself. This surprises people: you set up an RTCPeerConnection, but it has no idea who the other browser is or how to reach it. WebRTC leaves that step, called signaling, entirely up to you.
Signaling is the exchange of two things before a direct connection exists:
- A session description — each peer generates an offer or answer in the Session Description Protocol (SDP) format, describing what media and codecs it supports.
- Connectivity candidates — the possible network addresses each peer might be reachable at (more on these next).
You relay these blobs between the two peers over any channel you already control — and the natural choice is a WebSocket from Part 2, since both peers are already connected to your server. The server is a matchmaker that introduces the two browsers and then steps out of the media path.
Once the introduction is done, the server's job is over — the media flows directly. But "directly" hides the last, hardest step.
NAT traversal: punching through the network
Home and office devices hide behind Network Address Translation, so a browser rarely has a public address another browser can dial — WebRTC has to discover a path through. Network Address Translation (NAT) is why your laptop's address (192.168.x.x) is private and shared behind your router's single public one. It's great for security and address conservation, and terrible for two peers trying to connect directly.
WebRTC solves this with a framework called ICE (Interactive Connectivity Establishment), which gathers every possible way to reach a peer and races them to find one that works. It draws on two helper server types:
- STUN (Session Traversal Utilities for NAT) — a lightweight server a browser asks "what does my public address look like from the outside?" Armed with that answer, two peers can often connect directly through their NATs. STUN is cheap: it sends one small reply and then gets out of the way.
- TURN (Traversal Using Relays around NAT) — a fallback relay for when direct connection is impossible (strict corporate firewalls, symmetric NATs). The media flows through the TURN server, which forwards it between peers. This works anywhere, but you've reintroduced a server in the middle — with its bandwidth cost and latency — so it's the last resort, not the default.
The practical upshot: most WebRTC connections succeed peer-to-peer with only a cheap STUN server, but a meaningful minority need a TURN relay — so any serious deployment must budget for running one. Roughly one call in five needs relaying, and that fraction climbs sharply for locked-down corporate networks.
When not to reach for WebRTC
WebRTC is the right tool only when you truly need direct browser-to-browser media or data — otherwise its complexity outweighs the benefit. If your data already has to pass through your server anyway (persisting chat messages, authoritative game state), a WebSocket from Part 2 is simpler, easier to scale, and needs no STUN, TURN, ICE, or signaling dance. WebRTC earns its complexity for video and voice calls, screen sharing, peer-to-peer file transfer, and latency-critical games — cases where a direct path is the whole point.
The whole series, on one page
You now have the full toolbox for "beyond HTTP request–response." Each technology occupies a different point on one spectrum: how far it departs from a plain request, and in which direction data flows.
| Technology | Topology | Reach for it when… |
|---|---|---|
| Server-Sent Events | Server → browser | You need a simple live feed or token stream and the browser only listens. |
| Web Push | Server → browser (no page) | You must notify a user whose tab — or browser — is closed. |
| Beacon | Browser → server (on exit) | You must record something as the page is being closed. |
| WebSocket | Browser ↔ server | You need a proven two-way channel with ordered messaging. |
| WebTransport | Browser ↔ server | You need two-way traffic without head-of-line blocking, or unreliable datagrams. |
| WebRTC | Browser ↔ browser | You need direct peer-to-peer media or data, with no server in the path. |
The browser is far more than a request–response client. From a server that speaks first, to a channel both sides share, to browsers talking directly to one another — each of these is a different answer to the same limitation, and knowing which one fits is most of the battle.
Glossary
| Term | What it is |
|---|---|
| WebRTC | Web Real-Time Communication — browser-to-browser media and data connections. |
| Peer-to-peer (P2P) | A topology where two endpoints connect directly, not through a central server. |
RTCPeerConnection | The core WebRTC object managing media, data channels, and connectivity. |
| Signaling | The app-provided exchange that introduces two peers before a direct connection exists. |
| SDP | Session Description Protocol — the format describing a peer's media and codecs. |
| NAT | Network Address Translation — routers sharing one public address across private devices. |
| ICE | Interactive Connectivity Establishment — the framework that finds a working path between peers. |
| STUN | Session Traversal Utilities for NAT — a server that tells a peer its public address. |
| TURN | Traversal Using Relays around NAT — a relay used when direct connection fails. |
| SRTP / SCTP / DTLS | The secure transports carrying WebRTC media (SRTP) and data channels (SCTP over DTLS). |
References
- WebRTC API — MDN —
RTCPeerConnection, media, data channels, and the connection lifecycle. - Signaling and video calling — MDN — a worked example of building your own signaling over a WebSocket.
- RFC 8445 — Interactive Connectivity Establishment (ICE) — the NAT-traversal framework WebRTC uses.
- RFC 8489 — Session Traversal Utilities for NAT (STUN) — how a peer discovers its public address.
- RFC 8656 — Traversal Using Relays around NAT (TURN) — the relay fallback for when direct connection fails.