Browser Video Meetings With No Download: What Actually Works

WebRTC does the core call, reliably

The peer connection, the encoding, the network traversal — that's WebRTC, and it's been a browser standard long enough that it's not the risky part anymore. getUserMedia grabs your camera and mic with a permission prompt, the browser negotiates a connection (usually through a relay server for anything beyond two people), and video streams. This works the same way in Chrome, Edge, Firefox and Safari. If a meeting tool asks you to download something just to join the call itself, that's a product choice, not a technical requirement.

Screen sharing is native, but audio-with-it is not

getDisplayMedia is the API that lets a browser tab capture your screen, a window, or another tab, and it needs no extension. Sharing the tab itself works everywhere. Sharing your entire screen with system audio attached — so remote participants hear the video clip you're playing, not just your mic — only works reliably on Chrome and Edge on Windows and ChromeOS. On macOS, Chrome cannot capture system audio without a third-party virtual audio driver installed outside the browser, and Safari doesn't expose the option at all. If a meeting depends on someone hearing audio from your screen share, check the presenter's OS and browser before the call, not during it.

Virtual backgrounds run on your CPU or GPU, not a server

Background blur and replacement in a browser meeting is done with an ML segmentation model running locally via WebGL or WebAssembly — nothing gets uploaded to separate the person from the background. That means quality depends entirely on the hardware in front of you. A laptop with WebGL2 and a decent GPU handles it at full frame rate with clean edges around hair and hands. An older machine or one running on integrated graphics under load will drop frames or produce a smeared edge, and some very old browser builds don't expose the segmentation APIs at all, so the option simply doesn't appear.

Speech recognition is the biggest gap between browsers

This is where 'works in a browser' stops meaning 'works the same everywhere.' The Web Speech API's SpeechRecognition interface — the thing that turns your voice into text without sending audio to a separate app — is implemented well in Chromium-based browsers: Chrome and Edge. Safari has partial, inconsistent support that varies by version. Firefox has never shipped the recognition side of the API at all; it only implements speech synthesis, the reverse direction.

AVAY runs entirely in the browser and its live transcription and note-taking rely on this API, so the experience is solid in Chrome and Edge and noticeably weaker or unavailable in Safari and Firefox. That's not a bug to be fixed with a future release — it's a gap in what those browsers expose to any web page, and any tool that promises live transcription 'in the browser, no download' is making the same trade whether it says so or not.

Where a real app still wins

A handful of things genuinely need an installed application, and no amount of browser API progress has closed these yet. Background operation is one: a browser tab suspends or throttles when you switch away or lock your laptop, so notifications and recording can lag or stop, while a native app keeps a background process alive. Deep OS-level audio routing — capturing every app's output as a single mixed feed, not just one tab — is another; browsers sandbox audio per-tab by design, so a native app or a virtual audio driver is the only way around it. Multi-monitor screen share selection is also cleaner in a native client on some operating systems, where the browser picker only offers a flat list of windows with no live preview.

Common questions

Can I join a browser-based meeting on my phone with no app?

Yes for viewing and speaking — mobile Chrome and Safari both support WebRTC calling in-browser. Screen sharing from a phone browser is limited or absent on most mobile OS builds, and background tabs on mobile get suspended fast, so live transcription or notes can lag if you switch apps mid-call.

Why does live captioning work for a colleague but not for me on the same call?

It's almost always the browser, not the meeting tool. If they're on Chrome or Edge and you're on Safari or Firefox, the underlying speech recognition API either behaves differently or isn't implemented at all on your side, regardless of what the meeting platform does.

Is a browser meeting less secure than a downloaded app?

Not inherently — the media stream is encrypted the same way in both cases, since it's the same WebRTC transport underneath. The difference is what permissions you're granting: a browser asks per-session for camera, mic and screen, and revokes them when the tab closes, while a native app typically holds standing OS-level permissions between calls.

Do I need to install anything to use AVAY?

No — it runs in the browser tab, and the AI participant that takes notes and answers questions during the call runs there too. The trade-off is that its live transcription quality follows the same Chrome/Edge-versus-Safari/Firefox split as any browser tool built on the Web Speech API.

The short version

WebRTC makes the actual call — video, audio, screen share — genuinely download-free and consistent across browsers, but live captions and system-audio sharing are not: Chrome and Edge cover both well, Safari and Firefox leave real gaps that no meeting tool can code around.