Browser meeting microphone not working: permissions and WebRTC
Fix mic silence at permission and device layers before you switch meeting apps.
You are in the browser room. You hear everyone else. Your meter does not move, and they say they hear silence. The room ID is usually fine. Capture is stuck at permission, device, or the tab.
Treat browser meeting microphone not working as a stack: mute → site permission → OS privacy → input device. Do not install a desktop client as step one. In a no-login room on wbmeet, voice is already WebRTC in this tab.
Four layers — change one at a time
Flipping five settings at once hides the broken layer. After each step, ask someone to listen again.
- 1
Rule out in-room mute first
Check your mute control and any second tab holding the same mic. Close idle meeting pages. Get voice up before you turn cameras on.
- 2
Allow the site microphone and reload
Use the lock or tune icon in the address bar. Open site settings, set Microphone to Allow, then reload and rejoin. Browsers remember a prior Block. Clicking the in-room mic again will not override that.
- 3
Let the OS give this browser the mic
Windows: Settings → Privacy & security → Microphone, allow app access. macOS: System Settings → Privacy & Security → Microphone, enable Chrome, Edge, Safari, or Firefox. If the UI says managed by your organization, site toggles will not win — ask IT.
- 4
Pick the right input, then test WebRTC
Headsets, built-in mics, and virtual devices get crossed. Set the system default to the mic you are speaking into; unplug idle Bluetooth if needed. If site and OS both allow and you are still silent, use the guide connection notes: firewalls and corporate proxies often block UDP.
Usual stuck points — not a “dead room”
Permission lives on this profile
A new Chrome profile, a private window, or another browser is a new grant. Fixing profile A does not unlock the same room ID in profile B.
OS can block a “allowed” site
The site control shows Allow while the OS never listed this browser. Clear the OS layer, then reload the tab.
Capture conflicts beat “just use Zoom”
A recorder, a second call, or a virtual cable can own the mic. Stop other capture first. Then decide if you still need a heavy suite.
Match the symptom before you reshuffle settings
| What you see | Layer to check | Next move |
|---|---|---|
| UI says the mic is blocked | Site permission | Allow, then reload — mute alone will not fix it |
| Local meter stays flat | OS privacy or wrong input | Grant the browser; change default input |
| You hear echo; they hear you | Echo / extra capture tabs | Use headphones; close the second call |
| Permissions pass; nobody has media | WebRTC network | Switch network or check UDP, not the app store |
A no-install meeting trades “client permissions” for “this browser + this site.” Joining on a room ID proves signaling, not that the microphone is allowed.
# Chrome / Edge site microphone
Address-bar icon → Site settings → Microphone → Allow
Then reload the room tab
# OS layer (if the meter is still flat)
Windows: Settings → Privacy & security → Microphone
macOS: System Settings → Privacy & Security → Microphone- Allowing the site is not picking the mic
- Permission only lets the browser ask the device. Input can still sit on a dead Bluetooth or virtual cable. Speak into the mic you intend and watch the OS input meter.
- wbmeet will not bypass the prompt
- There is no desktop client that can force the microphone on. That limit is the product: voice lives in the tab, and the first use shows a browser or OS prompt — see features.
- Voice first, then video and share
- Rooms hold up to eight people; cameras have a tighter cap. Do not turn every camera on while the mic is dead. The board can be watched without a microphone.
Still unsure?
Same steps on a phone browser?
Same layers: Safari or Chrome app permission plus the system microphone switch. Backgrounding the tab can pause WebRTC. Use the phone to talk; edit a dense board on a larger screen.
Do I need to install Zoom to fix the mic?
No. Once site and OS permission pass, this browser can capture. Another client only asks for a second grant. It does not unlock a browser the OS has blocked.
They hear me, I do not hear them — is that my mic?
That is output or their capture: speakers or headset, system output device, and whether they are muted. Finish your mic checks; do not mix them with earpiece debugging.
Permissions are open and voice still will not connect?
Move to firewall, proxy, and UDP. A granted microphone only clears the device layer. On locked-down networks, light browser rooms and heavy suites can both fail. Switching networks is a faster test than switching apps.