WebRTC (Web Real-Time Communication) is an API for direct, real-time connections between peers. A browser exchanges audio, video, and data with another browser, or with any endpoint that implements the same protocols: a native app, a mobile SDK, a media server, a SIP gateway. The traffic goes to that peer instead of to a server that relays it.
This changes the usual client-server model. In that model, every browser talks to a server, and the server relays everything. WebRTC turns each browser into a network node. A node connects straight to another node, and the data travels between them. When a direct path exists, no server sits on it.
The same API ships in every evergreen browser. You build calls, file transfer, or multiplayer games on it without plugins.
Two standards, one name
WebRTC is two standards efforts under a single name. The W3C publishes the JavaScript API: RTCPeerConnection, RTCDataChannel, and the media model. The IETF publishes the protocol suite underneath: ICE, DTLS, SRTP, SCTP, and the rest of the stack. Neither half is usable without the other.
Media capture is a third piece, specified separately again. getUserMedia comes from Media Capture and Streams, getDisplayMedia from Screen Capture. Both feed every WebRTC call, and neither belongs to the WebRTC specification.
That split tells you where answers live. Object shape and API behaviour come from the W3C spec. Packet formats, negotiation rules, and failure modes come from the RFCs. References lists both sets.
How a connection forms
Two browsers cannot reach each other yet. They have never met, and they sit behind routers that hide their addresses. WebRTC opens the path in four steps.
Signaling comes first. Each peer describes what it can send and receive, and where it might be reachable. WebRTC does not define how this description travels. You move it out-of-band, through any channel you already control: a WebSocket server, a copied code, a URL. Signaling exchanges setup info only, never media.
ICE (Interactive Connectivity Establishment) finds a network path. Each peer gathers candidate addresses and tests them in pairs until one works. ICE is what gets a connection through NAT, the address translation that home and office routers apply.
The four steps depend on each other in that order, but they overlap in time. ICE gathering starts the moment a peer applies its own description, and the candidates it finds keep travelling over the signaling channel while the rest proceeds. That overlap is trickle ICE, and it is why a connection opens in a second instead of waiting for a complete candidate list.
DTLS then secures the link. The peers run a handshake and agree on keys. From that point, everything is encrypted. Encryption is mandatory in WebRTC; there is no plaintext mode.
Media and data flow last. Audio and video ride over SRTP. Arbitrary data rides over SCTP. Both go directly between the peers.
What peer-to-peer changes
Removing the server from the data path has three effects.
Latency drops. Data takes the shortest route between two peers instead of a round trip through a server.
Traffic stays private. Audio, video, and data are not routed through, stored on, or readable by any host. The peers hold the keys.
Bandwidth cost shifts to the participants. There is no central host paying to relay every byte. Each peer carries its own connection.
The tradeoff is real. NAT traversal can fail. Some routers and firewalls refuse every candidate pair ICE can offer, and then the connection never opens. The usual fix is a TURN relay, a server that forwards the encrypted traffic when a direct path is impossible. This site is STUN-only. It uses public STUN servers to discover addresses but adds no TURN relay. That keeps gameplay traffic strictly peer-to-peer. The accepted cost: a few restrictive networks will not connect. That is a deliberate limit, not a bug.
The three building blocks
Three APIs work together. Two are WebRTC proper; the third comes from the capture specs.
RTCPeerConnection is the connection. It runs the handshake, manages ICE, and holds the encrypted link between two peers.
RTCDataChannel carries arbitrary binary or text data over that link, the way a WebSocket would, but peer-to-peer.
MediaStream is the container for the audio and video tracks that ride the link. It captures nothing by itself: getUserMedia builds one from the camera and microphone, getDisplayMedia from a screen, window, or tab.
Connecting covers how these fit together when two browsers open a path.
Where it's used
WebRTC powers anything that needs direct, low-latency exchange between browsers:
- Audio and video calls, one-to-one or in groups.
- Live streaming to many viewers.
- Messaging over the data channel.
- File transfer straight between two browsers.
- Screen sharing of a tab, window, or display.
- Multiplayer games, where inputs and state pass peer-to-peer.
Every game on this site runs on the same plumbing. See Security for how the encrypted link is built and verified.
The Learn track
Read the eight overviews in order. Each one introduces a topic and links into its deep dives.
- Connecting: how two browsers find each other and open a direct path.
- Calls: one-to-one and group audio and video.
- Streaming: one-to-many broadcast at low latency.
- Messaging: the data channel for arbitrary peer-to-peer data.
- File transfer: sending files directly between browsers.
- Screen sharing: capturing a screen, window, or tab.
- Security: mandatory encryption and authentication.
- Debugging: reading connection health with the Stats API.