What Is WebRTC? Real-Time Video in the Browser Explained

Every time you join a video call in a browser without installing anything, you are using WebRTC. So what is WebRTC, exactly, and why do live streaming engineers get excited about it? In short, it is a set of open standards that lets browsers and apps send audio, video and data in real time, with a delay measured in fractions of a second. This guide explains how it works, why it is so fast, where it struggles and when it is the right choice for your video project.

A short definition

WebRTC (Web Real-Time Communication) is a collection of browser APIs and network protocols, standardised by the W3C and the IETF, for real-time media. It is built into Chrome, Edge, Firefox and Safari on desktop and mobile. Google released the original code as open source in 2011, and the core specifications became formal standards around 2021.

It was designed for conversation. In a call, more than a few hundred milliseconds of delay makes people talk over each other, so every part of WebRTC is tuned to keep latency tiny.

What WebRTC is made of

You do not need to know every piece, but a few names come up constantly.

getUserMedia. The browser API that asks for camera and microphone access and returns a live media stream.

RTCPeerConnection. The object that manages a connection to another peer or server: codecs, encryption, network paths and quality adaptation.

Data channels. A way to send arbitrary data alongside audio and video, used for chat, game state or file transfer.

Signalling. Before two sides can connect, they must exchange information about codecs and network addresses. WebRTC deliberately leaves this to you. Apps use WebSockets, HTTP or anything else to pass these messages.

ICE, STUN and TURN. Most devices sit behind routers and firewalls. ICE is the process of finding a network path that works. A STUN server tells a device what its public address looks like from outside. When no direct path exists, which happens on strict corporate and mobile networks, a TURN server relays the media. TURN is essential for reliability and is often the most expensive part of running WebRTC at scale.

SRTP and DTLS. All media is encrypted. There is no unencrypted mode.

Why WebRTC is so fast

Traditional streaming such as HLS sends video in segments over HTTP, which runs on TCP. TCP guarantees that every packet arrives, in order. If a packet is lost, everything waits while it is resent. Add player buffering, and you get delays of 5 to 30 seconds.

WebRTC takes the opposite approach:

• It sends media over UDP using RTP, so there is no built-in waiting for lost packets.
• The receiver keeps a tiny jitter buffer, often tens of milliseconds.
• When packets are lost, the system uses error concealment, forward error correction or quick targeted retransmission, rather than stopping everything.
• Congestion control lowers the bitrate the moment the network struggles, instead of letting a queue build up.

The result is glass-to-glass delay that is usually well under a second. For a full comparison with LL-HLS and LL-DASH, see our guide to low-latency streaming.

Peer-to-peer, SFU and MCU

How the media travels changes everything about cost and scale.

Peer-to-peer (mesh). Each participant sends directly to every other participant. Fine for a one-to-one call. With five people, each device uploads four copies of its video, which quickly becomes impossible.

SFU (Selective Forwarding Unit). Each participant sends one stream to a server, which forwards it to everyone else. The server does not decode or mix video; it just routes packets. This is how almost every modern group call and WebRTC broadcast works. It scales well and keeps latency low.

MCU (Multipoint Control Unit). The server decodes everyone’s video, mixes it into one picture and re-encodes it. Easy on clients, very heavy on servers. Rare today except for legacy systems and recording.

For broadcasting to large audiences, SFUs are chained into networks, sometimes called WebRTC CDNs, that fan one stream out to tens of thousands of viewers.

Codecs in WebRTC

Browsers must support at least VP8 and H.264 for video, and Opus for audio. Most also support VP9, and support for AV1 is growing. Two techniques help with mixed audiences:

• Simulcast: the sender encodes the same video at two or three qualities, and the SFU forwards the right one to each viewer.
• SVC (scalable video coding): a single stream contains layers that can be dropped for weaker viewers. VP9 and AV1 support it.

These play the same role in WebRTC that adaptive bitrate plays in HLS and DASH.

WHIP and WHEP: WebRTC for streaming

For years, using WebRTC for broadcasting meant custom signalling for every platform. Two IETF standards fixed that:

• WHIP (WebRTC-HTTP Ingestion Protocol) lets an encoder publish a WebRTC stream to a server with a simple HTTP request. Recent versions of OBS support WHIP output.
• WHEP (WebRTC-HTTP Egress Protocol) does the same for players.

With WHIP and WHEP, WebRTC slots into streaming workflows alongside RTMP and SRT. Our comparison of RTMP vs SRT vs WebRTC looks at the ingest side in detail.

Where WebRTC shines

• Video calls and meetings. Its original purpose.
• Remote guests on live shows. Guests join from a browser link; the producer mixes them into the programme.
• Live auctions, betting and quizzes. Everyone must see the same moment at the same time.
• Live shopping with real-time questions.
• Remote production and monitoring, where a director needs to see a camera feed instantly.
• Cloud gaming and interactive apps.

Where it struggles

• Very large audiences. HTTP streaming rides on ordinary CDNs, which are cheap and enormous. WebRTC needs specialised servers for every viewer connection, so cost per viewer is higher.
• Picture quality under constraint. WebRTC favours low delay over perfect quality, so it lowers resolution quickly on weak networks.
• DRM. Premium content protection is mature for HLS and DASH and much more limited for WebRTC.
• Recording and replay. You need extra components to record streams and make them available on demand.
• Operational complexity. TURN servers, SFU clusters and signalling all need running and monitoring.

That is why many services use a hybrid: WebRTC for hosts, guests and a premium real-time tier, and HLS for the large passive audience.

A simple way to try it

Open a browser-based meeting service and join from two devices on different networks. Mute one device and speak into the other. Notice how quickly your voice arrives, compared with the 10 to 30 seconds of a typical live stream on YouTube or Twitch. That gap is the whole reason WebRTC exists.

For a technical view, open chrome://webrtc-internals in Chrome during a call. It shows every connection, the chosen network path, codec, bitrate, packet loss and round-trip time, updating live.

Planning bandwidth

Each WebRTC viewer receives their own stream from the SFU, so server bandwidth grows with the audience, just as with a CDN. The difference is price: WebRTC delivery is usually more expensive per gigabyte. Use the bandwidth calculator to estimate peak and total traffic, then compare vendors’ per-minute or per-gigabyte pricing.

What it costs to run

Pricing for hosted WebRTC services is usually per participant-minute or per viewer-minute, sometimes with separate charges for recording and TURN relay traffic. That is different from HTTP streaming, where you pay mainly for gigabytes delivered by a CDN.

For small interactive events, such as a webinar with a few speakers and a hundred attendees, the difference is modest and the experience is far better. For a large broadcast with thousands of passive viewers, WebRTC delivery can cost several times more than HLS. That is why hybrid designs are so common: speakers and a small interactive group on WebRTC, everyone else on HLS a few seconds behind.

If you run your own infrastructure, open-source SFUs such as mediasoup, Janus, Jitsi Videobridge, LiveKit and Pion-based servers are mature and widely used. The software is free; the servers, bandwidth, TURN relays and the people to operate them are not. Plan for monitoring from day one, because WebRTC problems tend to show up as vague “it froze” complaints unless you log connection quality per session. For a broader view of what a full platform involves, see how to build a live streaming platform.

The one-line answer

WebRTC is how browsers talk to each other in real time. If your viewers need to react, reply or bid in the moment, it is the right tool. If they just need to watch, HLS is cheaper and simpler.

Summary

WebRTC is the open standard behind browser video calls, and it delivers audio and video in under a second by using UDP, tiny buffers, fast congestion control and built-in encryption. Signalling, STUN and TURN get connections through firewalls, and SFUs route media for group calls and broadcasts. It is ideal for interaction, remote guests and anything where timing matters, while HLS and DASH remain cheaper for very large passive audiences. With WHIP and WHEP, it now fits neatly into modern streaming pipelines.