TL;DR: WebRTC is an open standard built into browsers that lets devices send audio, video, and data to each other directly, encrypted by default. It powers essentially every modern video platform. It is a transport capability, not a product, which is why saying a tool is built on WebRTC tells you almost nothing about it.
WebRTC turns up in almost every video platform’s marketing, usually presented as a differentiator. It is not one. Zoom, Teams, Meet, and nearly every API vendor rely on it.
Understanding what the standard covers, and more usefully what it does not, is the fastest way to read past vendor claims.
WebRTC, short for Web Real-Time Communication, is an open standard supported by all modern browsers. It lets two devices exchange audio, video, and arbitrary data directly, with encryption applied automatically. No plugin or download is required, which is why browser-based video calls became normal.
Before WebRTC, video in a browser meant Flash or a desktop installer. The standard removed that barrier, which is the single reason joining a meeting by clicking a link is now unremarkable.
It handles capturing camera and microphone, negotiating how two devices will talk, encrypting the media, and adapting quality as network conditions change. That is a substantial amount of hard engineering given away for free.
What does WebRTC not do?
It does not define how two devices find each other, how to connect more than two of them, how to record a session, or how to control who is allowed to join. Those gaps are deliberate, and filling them is what every video platform and API vendor actually sells.
- Signalling: exchanging connection details before a call can start is left entirely to the application
- Group calls: direct connections stop working past roughly four to six people, so larger meetings need a media server
- Firewall traversal at scale: relay infrastructure is required when direct connections are blocked
- Recording: nothing in the browser combines participants into a stored file
- Access control: who may join, and with what permissions, is entirely an application concern
The scope was kept narrow on purpose so browser vendors could implement it consistently. The practical result is that WebRTC gets you a working two-person call and leaves the production problems to you.
Is WebRTC secure?
Media is encrypted in transit as a mandatory part of the standard, so it cannot be switched off. That protects data moving between endpoints. It says nothing about who is permitted to join a meeting, where recordings are stored, or which jurisdiction governs that data.
This distinction gets blurred often, sometimes deliberately. Encryption in transit is table stakes and every WebRTC platform has it. It is not a differentiator and it is not access control.
The questions that actually differentiate platforms sit above the standard: can you require authenticated users, issue per-person join links, separate host from participant privileges, restrict joining by country, and choose where meeting data lives. Convay handles those through role-based access control, end-to-end encryption, and digital sovereignty controls.
So when a vendor cites WebRTC encryption as proof of security, the useful follow-up is simple: what stops an unauthorised person from joining?
Frequently Asked Questions
WebRTC, short for Web Real-Time Communication, is an open standard supported by all modern browsers. It lets two devices exchange audio, video, and data directly, with encryption applied automatically and no plugin or download required.
The standard itself is free and built into browsers. Running a real service is not, because you still need signalling, media servers for group calls, relay infrastructure for restrictive networks, and recording. Those pieces are what video API vendors charge for.
Yes, encryption of media in transit is mandatory in the standard and cannot be disabled. That protects data moving between endpoints, but it does not control who may join a session, where recordings are stored, or which jurisdiction governs that data.
Essentially every modern video platform relies on WebRTC for browser-based calling, though most also ship native applications using their own stacks. Because it is near universal, a vendor claiming to be built on WebRTC is not telling you anything that distinguishes them.
Using direct connections alone, roughly four to six before upload bandwidth and CPU become limiting. Beyond that a media server such as an SFU is required, which is why every platform supporting large meetings runs server infrastructure rather than relying on the browser standard alone.
Related guides
- Start with the complete video conferencing API guide
- See when to use an API layer instead of raw WebRTC
- Learn what an SFU is and why group calls need one
- Learn what TURN is and why it costs money
Looking past WebRTC to what actually differentiates platforms?
Access control, deployment options, and jurisdiction are where platforms genuinely differ. We will answer all three directly against your requirements.
