When you press Start on JustChill Live, a stranger appears on your screen within seconds, live and in full video. You did not install an app, you did not create an account, and you did not download a plugin. It all happens inside your browser. The technology that makes this possible is called WebRTC, short for Web Real-Time Communication.
WebRTC powers a huge share of the video calls people make every day, including many well-known meeting and messaging services. Yet most people have never heard of it. This article explains what it is, how a call actually gets set up, and why it matters for the speed, quality and privacy of random video chat.
A short history
Before WebRTC, live video in the browser usually required a plugin such as Adobe Flash or a dedicated desktop application. Early random chat sites relied on Flash, which was slow, insecure and eventually abandoned. In 2011, Google released the WebRTC project as open source, and standards bodies (the W3C for the browser interfaces and the IETF for the network protocols) began turning it into an official web standard. Over the following years, every major browser added support. Today Chrome, Firefox, Safari and Edge all support WebRTC, on desktop and mobile, with no installation required.
The three jobs WebRTC does
WebRTC is not one single thing. It is a collection of technologies that together handle three jobs:
- Capturing media. Getting video from your camera and audio from your microphone, with your permission.
- Connecting peers. Finding a network path between two devices, even when both sit behind home routers and firewalls.
- Sending data securely. Streaming audio, video and text between the devices in real time, encrypted.
Let's look at each.
Step 1: Getting your camera and microphone
When you start a chat, the website asks the browser for access to your camera and microphone using an interface called getUserMedia. This is the moment your browser shows a permission prompt. Nothing is captured until you allow it, and browsers show an indicator, usually a dot or icon in the tab or address bar, while the camera is in use.
The browser then produces a media stream: a live feed of video frames and audio samples. You see your own feed in the small preview window, and the same stream is what will be sent to your chat partner.
Step 2: Signalling, or introducing two strangers
Here is the interesting part. Two browsers cannot connect to each other out of nowhere. They first need to exchange some information: what kind of video and audio each supports, and what network addresses each can be reached on. This exchange is called signalling.
WebRTC deliberately does not specify how signalling should work, leaving it to each application. On JustChill Live, signalling happens through our server using a real-time connection (WebSockets via Socket.IO). When our matching system pairs you with someone, as explained in how random matching works, the server acts as a go-between that passes a few messages back and forth:
- An offer. One browser describes its capabilities in a format called SDP (Session Description Protocol): which codecs it supports, what media it wants to send, and security fingerprints.
- An answer. The other browser replies with its own description, agreeing on a common format.
- ICE candidates. Both browsers share possible network addresses where they can be reached.
Once this exchange is complete, the server's job for the video itself is essentially done. It introduced the two browsers; now they talk directly.
Step 3: Finding a path through the network
Most devices do not have a simple public address. They sit behind routers using NAT (Network Address Translation), which lets many devices share one public address but makes direct incoming connections difficult. WebRTC solves this with a framework called ICE (Interactive Connectivity Establishment).
Each browser gathers candidate addresses: its local address, its public address as discovered by asking a STUN server, and, if configured, a relay address on a TURN server. The browsers then try pairs of candidates until one works. This all happens in a fraction of a second. We explain it in more depth in STUN, TURN and NAT explained.
Step 4: Streaming, encrypted by default
Once a path is found, audio and video flow directly between the two browsers. This is what peer-to-peer means. Encryption is mandatory in WebRTC: the browsers perform a DTLS handshake to agree on keys, and media is sent using SRTP (Secure Real-time Transport Protocol). There is no option in the standard to send unencrypted media, which is one of the reasons WebRTC is considered a secure foundation for video calls.
WebRTC also constantly adapts to network conditions. If your connection becomes congested, the browser lowers the video resolution or frame rate to keep the call smooth rather than letting it freeze. That is why video sometimes looks blurry for a moment and then sharpens again. Our article on improving video quality on slow internet explains what you can do to help.
Data channels: more than video
WebRTC can also send arbitrary data directly between browsers using data channels. JustChill Live uses a data channel for the in-call text chat, so the messages you type go directly to your partner's browser alongside the video. We explore this in how in-call text chat works.
Why WebRTC is good for random video chat
- No installation. Anyone with a modern browser can start instantly, which is essential for a spontaneous format.
- Low latency. Direct connections usually mean less delay, so conversation feels natural rather than like a walkie-talkie.
- Encryption by default. Media is always encrypted in transit.
- Adaptive quality. Calls stay usable across a wide range of connection speeds, from fibre to mobile data.
- Open standard. It is maintained publicly and implemented by all major browser makers, with constant security updates.
Trade-offs worth knowing
No technology is perfect. Peer-to-peer connections mean the two devices learn each other's network addresses, which we discuss in peer-to-peer video and your IP address. Some restrictive networks, such as certain corporate or school firewalls, block the kinds of connections WebRTC needs, which can cause a call to fail even though the match was made. And on very weak connections, no amount of adaptation can deliver clear video.
In summary
When you press Start, your browser asks for your camera, our server finds you a partner and passes a short exchange of offers, answers and addresses between you, your browsers find a network path, and encrypted video flows directly from one screen to the other. All of that happens in a second or two, invisibly. The next time a stranger's face appears on your screen almost instantly, you will know how much quiet engineering made that moment possible.