There was a time when video calling meant installing something — a plugin, a client, sometimes Flash. None of that is necessary anymore for browser-based video chat, and it's worth understanding the three specific pieces of technology that made the download disappear.
Modern browsers include a set of capabilities built directly into the browser engine itself, rather than relying on an external plugin to provide them.
The standardized way a website requests access to your camera and microphone. It runs inside the browser's security sandbox, which means a site can ask for your camera feed without ever getting broader access to your device or file system.
The core engine that actually establishes and manages the direct connection between two browsers — handling codecs, security, and the connection itself.
A channel for sending other kinds of data — text messages, file transfers — over the same secure, low-latency connection used for video, rather than needing a separate system for it.
It's worth being precise about device support rather than overstating it: high-resolution video and advanced audio features continue to improve across browsers and devices, but exact capabilities still vary depending on the specific browser, device, and camera hardware involved — there isn't a single universal capability guaranteed across every setup.
The biggest technical obstacle to a direct browser-to-browser connection is that most devices sit behind a router or firewall, which hides their real network address. WebRTC solves this with a process called ICE, which gathers possible connection paths and tests them to find the best one.
Tells a device its own public-facing address, so the other side knows where to send data.
Steps in as a relay specifically when a direct connection genuinely can't be established — certain strict corporate or institutional networks, for instance.
Independent estimates suggest somewhere in the range of 15 to 30% of connections sit behind network conditions restrictive enough to need this kind of relay fallback rather than a fully direct path — the exact figure varies by source and by the specific population being measured, so it's worth treating as an approximate range rather than a precise number for any one platform. What's accurate and worth being honest about: even with TURN available, no NAT traversal system achieves a guaranteed, perfect success rate — some network configurations remain genuinely difficult, and connection issues, while uncommon, do still happen. Claiming otherwise would overstate what any system can actually promise.
WebRTC mandates encryption as part of the standard itself, not as an optional feature a platform chooses to add. Two protocols handle this: DTLS manages the secure handshake that exchanges encryption keys safely, and SRTP encrypts the actual media itself. Even if someone intercepted the data in transit, they'd see only encrypted noise, not usable video or audio. Because this is built into the browser itself rather than a separate app, it also benefits from how quickly browsers like Chrome and Safari ship security updates — generally faster than a standalone downloaded application would.
WebRTC implementations continuously estimate available bandwidth in real time and adjust accordingly. If a connection gets weaker — moving from solid Wi-Fi to a congested mobile network, for instance — the browser detects the increased packet loss and lowers resolution or bitrate to keep the call going rather than letting it fail outright. We cover a genuinely useful, non-obvious trick related to this — about how your background affects this adaptation — in our guide on improving video quality on a weak connection.
It's easy to file "no download required" under pure convenience, but it has a real security implication worth naming too. A downloaded application runs with broader access to your device than a website does, and you're trusting that specific application's developer to handle security updates responsibly and indefinitely. A browser-based tool runs inside the browser's sandbox, with access limited to exactly what it requests (your camera, your microphone) and nothing more by default, and it inherits the browser's own security update cycle rather than depending on a smaller team to patch a standalone app. That's a meaningfully different trust model, not just a different installation experience.
It's worth knowing about a real, documented WebRTC quirk: by default, it can sometimes reveal a local network address even while a VPN is active, since some of the connection-setup process can bypass a VPN's tunnel. Most modern browsers now mask this using a technique called mDNS, which hides the literal local address. It's worth understanding this rather than assuming it's automatically and completely handled in every situation — we cover the fuller picture, including what actually helps, in our guide on staying anonymous on video chat.
Newer approaches like WebTransport, built on the HTTP/3 protocol, are an active area of development that may eventually improve multi-person group calls and higher-resolution streaming. It's worth treating this as reasonable industry-wide direction rather than a confirmed feature timeline for any specific platform — the underlying standards work continues, but exactly how and when it shows up in everyday video chat is still developing.
The download disappeared because browsers absorbed what used to require a separate plugin or application — camera access, a direct connection engine, encrypted data transport, all built into the browser itself. None of it is perfect or guaranteed in every situation, but it's genuinely good enough, most of the time, that millions of video calls happen every day without anyone needing to install anything at all.
For more on how the underlying connection process works, see our guides on how WebRTC actually works and what a signaling server actually does.