Browser meeting camera not working: permission, in-use, and room cap
Fix a dead camera at permission, in-use, and the four-seat cap before you switch meeting apps.
You are in the browser room. They hear you. The camera is black, says the device is in use, or the UI says this room is already at the video cap. The room ID is usually fine. Capture is stuck: site permission, OS camera, another app holding the device, or a taken camera seat.
Treat browser meeting camera not working as a stack: turn camera on in-room → allow the site → OS grants this browser → confirm a seat is free. Do not install a desktop client as step one. In a no-login room on wbmeet, video is already WebRTC in this tab. Voice and the board can start first; cameras are the tighter seats.
Four steps — change one layer at a time
Flipping permission, browser, and network together hides the broken layer. After each step, ask someone to look at the picture.
- 1
Confirm the site may use the camera
In the lock icon on the address bar, Camera must be Allow. A past Block stays on the origin. Changing the room ID does not clear it. Set Allow, reload the tab, then try again. If another tab already holds the same camera, close that tab first.
- 2
Give this browser Camera in the OS
macOS: System Settings → Privacy & Security → Camera. Enable Chrome, Edge, Firefox, or Safari, then quit the browser completely and reopen. Windows: allow desktop apps to use the camera. Preview windows, Zoom, or another meeting client holding the device show “in use”.
- 3
Confirm the room still has a camera seat
wbmeet rooms cap at eight people, but simultaneous cameras default to four. If the UI says busy or full, ask people who are not presenting to turn video off and stay on voice plus the board. That is the mesh limit, not a dead room. See camera and capacity limits.
- 4
Rule out insecure context and a mushy link
Use https, or
localhost/127.0.0.1on this machine. IDE embedded previews usually cannot capture. If the picture is soft or stuck, turn your video off first, then use the guide: firewalls and proxies often block UDP.
Usual stuck points — not a “dead room”
One Block and the origin stays dark
The browser stores Block on the site. A new room ID does not reset it. Flip the lock icon to Allow and reload.
The four-seat cap beats “just use Zoom”
A fifth camera hits the default limit. Ask two people to stop video. Heavy suites often cap concurrent video too. Switching apps does not free a seat that is already taken.
Another process owns the same camera
The site button still clicks. The OS gave the device to a preview window or another client, so you get black frames or “in use”. Quit those processes first.
Match the symptom before you reshuffle settings
| What you see | Layer | Next move |
|---|---|---|
| Browser says camera is blocked | Site permission | Allow in the lock icon and reload |
| “Busy” or at the video cap | Four-camera seat | Ask others to stop video, then start |
| OS says the device is in use | Another app holds the camera | Quit preview / other meeting apps |
| Camera starts but looks stuck or soft | Bitrate or network | Turn video off, or check UDP |
A no-install meeting trades “client video on” for “this browser + this grant.” Joining on a room ID proves signaling, not that a camera was allowed or that a seat is free.
# Chrome / Edge / Firefox
Address-bar lock → Camera: Allow → reload tab → enable camera
# macOS still black or in use
System Settings → Privacy & Security → Camera
Enable this browser; quit other apps holding the device
# Secure context
https:// or http://localhost / 127.0.0.1- Voice and board first, video second
- Most standups and reviews do not need faces. One presenter camera is enough. The whiteboard does not consume a camera seat.
- wbmeet will not skip permission or the cap
- There is no desktop client that forces a camera on. Eight people per room, cameras tighter — see features.
- Video costs the mesh more than the mic
- Do not turn every camera on while the mic is dead. On a weak link, drop video and keep voice. That test is faster than switching suites.
Still unsure?
Do I need a camera to join?
No. Voice and the whiteboard are enough. Cameras are optional seats. A full video cap does not block listening or drawing.
Do I need Zoom to turn video on?
No. Current Chrome, Edge, Firefox, and some Safari builds can capture once permission passes and a seat is free. Another client only asks for a second grant. It does not unlock a blocked browser or a full four-seat room.
Is a phone-browser camera reliable?
Fine for joining and talking. Backgrounding can pause WebRTC. Heavy board work is easier on a larger screen. Grant camera again in the OS prompt.
Permissions are open and the picture is still gone?
Move to WebRTC network: firewall, proxy, UDP. A grant only clears capture. On locked-down networks, light rooms and heavy suites can both fail. Switching networks is a faster test than switching apps. See connection troubleshooting.