What is WebRTC, and how does browser video chat work?

Your browser can handle a live call because it already contains tools for sending sound and pictures. WebRTC is the name for those communication building blocks. A website uses them to request your camera, arrange a connection and deliver the call. You don't need to understand their code to understand their limits.

What does WebRTC actually do?

The name stands for Web Real-Time Communication. “Real-time” means the technology is built for an ongoing exchange, where waiting for a whole recording would make conversation difficult. Your device sends small pieces while the call continues, and receives the other person's pieces along the way.

The WebRTC project's peer-connection guide describes connections that carry audio, video or other data. For you, that might appear as a video window, an audio-only call or a shared activity. The browser features sit underneath the buttons you press.

Think about the difference between making a voice recording and calling someone. A recording can finish before anyone receives it. A call needs to keep sending while you speak, then make room for the reply. WebRTC gives developers tools for that ongoing exchange; it doesn't decide who you should call.

How does a browser video call start?

There are several jobs hiding behind one call button. The page asks the browser for access to the selected microphone or camera. It also exchanges setup information with the other end, so both sides know what they can send and how they might connect.

That setup exchange is called signalling. It's closer to agreeing where a conversation will happen than to carrying the conversation itself. The service provides the signalling channel; WebRTC doesn't prescribe one particular way to build it. This is why two services can use the same browser technology while behaving quite differently.

Imagine two people joining a remote drawing lesson. Before either sees a pencil move, their devices agree on compatible call settings and find a workable route. Once connected, the live picture travels along the chosen route. The lesson's booking page, teacher list and payment system are separate parts of the service.

Does WebRTC need a server?

Usually, yes. A service normally uses a server to help the two ends find each other and exchange setup information. Even when the picture travels directly between devices, a server may still handle accounts, room access or connection setup. “Peer-to-peer” describes a possible media route, not the whole website.

Some networks won't allow a workable direct route. The call can then pass through a relay server, which forwards the traffic. A relay can be what makes the call possible from a particular home, workplace or mobile network. Its presence doesn't mean the technology has stopped being WebRTC.

The W3C specification allows communication with another browser or another compatible endpoint. That endpoint can be part of a service's infrastructure. So you can't look at a browser call and know, from its appearance alone, exactly which servers participate.

Why does it ask for my camera and microphone?

A calling page needs permission to use those inputs. According to MDN's camera and microphone documentation, browsers must get permission and show an indicator when a camera or microphone is being used. They also distinguish permission from active use.

You might have allowed a site to remember your choice. In that case, a later visit may not bring up the same question. The absence of a new popup doesn't necessarily mean permission was bypassed. Check the site's browser permissions if you want to review what you've allowed.

Permission to access your camera is also different from agreement to show yourself to a particular person. A preview can help you see the frame before joining, where the service provides one. Our guide to asking before switching to video covers the social agreement that a browser popup can't make for you.

Is WebRTC secure?

WebRTC includes encrypted transport. The W3C requires browsers to encrypt transmitted data with session-specific keys. That protects the communication as it crosses the network. You don't need to find an optional “make WebRTC encrypted” setting for that basic requirement.

The harder question is where the protected connection ends. It might end at the other person's device, or at a server participating in the call. A service's architecture determines what happens after that. The phrase end-to-end encryption therefore needs a more specific explanation than “we use WebRTC.”

Encryption also doesn't establish the other person's identity, stop them copying what they receive, or tell you which connection records a provider keeps. Those are separate questions. A useful privacy page answers them separately instead of using one technical name as a complete reassurance.

Is WebRTC an alternative to Zoom?

They belong to different categories. WebRTC is technology that developers can use. Zoom is a finished communication service, with joining flows, controls and policies. Comparing them directly is like comparing a video format with a particular video player: one may help the other work, but they aren't interchangeable purchases.

For an everyday choice, look at the service you will actually use. Can both people join on their devices? Are leaving, muting and reporting easy to find? Does the privacy explanation say what is stored? A technology label alone won't answer those questions.

You may also see WebRTC used outside an ordinary two-person call. Its data connections can support interactive features, while its media connections can support different call arrangements. None of that requires you to memorise the names of the browser's programming tools.

What should you try before your next browser call?

Make a short rehearsal with someone you trust. The purpose is to learn the controls while the stakes are low, not to inspect the whole network. Choose an ordinary subject, such as showing a folded paper shape.

1. Review access before joining. You could say: “Going to check which microphone this page selected before we start.”
2. Test the outgoing view if a preview exists. You could say: “The preview shows more of the room than expected, so adjusting the angle first.”
3. Check one control at a time. You could say: “Muting for a moment; please tell me when the sound stops.”
4. Practise leaving. You could say: “Ending this test call now, then checking that the camera indicator goes off.”

Keep the video chat preparation guide nearby if you're trying a new service. Learning where the controls are is more useful than knowing every abbreviation on its technical page.

What changes when you mute or turn off video?

The visible controls belong to the calling service, so their exact behaviour matters. Muting usually stops your microphone sound reaching the conversation. Turning off video usually stops your live picture appearing to others. Neither button necessarily ends the session or signs you out of the service.

Check the labels rather than treating all red buttons alike. “Leave call,” “stop camera” and “close preview” describe different actions. If you're unsure which action you took, ask the other participant what they can still hear or see during your rehearsal.

It's useful to separate three checks: the page's own button state, the browser's camera or microphone indicator, and what the recipient actually receives. Those checks answer different questions. A muted microphone icon inside a page isn't a complete description of the browser's permissions, and saved permission isn't proof that a live feed is currently being sent.

What if the call doesn't work?

A failure can happen before permission, during connection setup or after the media starts. Note which stage failed. “Camera preview works, but the other person never connects” is more useful to support than “video is broken.” It narrows the problem without assigning blame.

If the camera indicator stays active after you expected the call to finish, close the calling page and review its permissions. If problems continue, contact the service's support with the browser, device and exact symptom. The plain-language technology hub can help you understand the terms in their reply.