Screen Sharing Not Working? A 5-Minute Browser and Network Check
Run a quick readiness check for screen-share permissions, microphone, camera, codecs, and network, then fix the exact failure before your call.
Screen sharing failures are rarely random. Work from the failing check instead of guessing, because the cause is usually one of four things:
- The browser or HTTPS context.
- A permission the site was not granted.
- A missing or muted device.
- A network blocking live media.
Open the Screen Share Test and start with the row marked red. If you are sharing for work, the CISA guidance for securing video conferencing adds organization-level controls for who is allowed to share.
Key takeaways
- Screen capture needs a current desktop browser and a secure context (HTTPS or localhost).
- A green capability row with a failed device test usually means a blocked permission, not broken hardware.
- On macOS, Screen Recording, Microphone, and Camera are granted in System Settings, and a change needs a browser restart.
- A network test that finds only local addresses points to a firewall, VPN, or DNS filter blocking WebRTC.
- Hearing your voice but not the video is a picker choice, not a failure: tick the tab or system audio box.
The 30-second check
The test opens with a browser readiness list. It checks HTTPS, the Screen Capture API, camera and microphone access, WebRTC, WebSocket, and the VP8/H.264 and Opus codecs. WebRTC is the browser standard for real-time audio and video, and it is the layer a live room depends on. A green result means the capability exists; a red one tells you where to look. Below it, separate buttons test screen capture, the microphone, the camera, and the network.
Fix browser and secure-context problems
Screen capture only runs over HTTPS (or localhost) and only in a current desktop browser. A secure context is a page served over HTTPS or from localhost, and browsers block capture anywhere else (see MDN on secure contexts). If the HTTPS or Screen Capture API row fails, update the browser, avoid stripped-down or in-app browsers, and make sure the page is loaded over https:// rather than a saved local file.
Fix permission problems
If the browser row is green but a device test fails, a permission is likely blocked, for instance a camera the browser denied earlier and then remembered. Check the site permissions (the padlock or camera icon in the address bar) and allow screen, microphone, and camera as needed. On macOS, also open System Settings, Privacy & Security and enable Screen Recording, Microphone, and Camera for the browser; a change there often needs a browser restart.
Fix device problems
The microphone test shows a level meter — if it never moves, the input is muted, the wrong device is selected, or another app has exclusive use. The camera test shows a preview and the actual resolution. If a device is missing entirely, the operating system does not see it and no browser setting will help.
Fix network problems
Live sharing needs to reach a public relay address. The network test gathers WebRTC candidates against a public STUN server and reports whether it reached one. A STUN server is a public helper that reports the address your network can be reached at, so two peers can find each other. If the test only finds local addresses, a corporate firewall, VPN, or DNS filter is likely blocking the media path, for example a VPN that drops UDP traffic, as described in the Screen Capture specification's connectivity requirements. Try a different network, disconnect the VPN, or ask IT to allow WebRTC (UDP) traffic.
This is the same connectivity a live room uses. If the network check fails, a room may connect for signaling but never show video.
Audio problems after the share starts
A working setup can still look broken if viewers hear your voice but not the video. That is not a failure — it is the browser picker choice. The microphone reaches the room through getUserMedia(), while the content's sound is a separate track. When you share a tab or screen, tick Share tab audio or Share system audio so that track is sent too. The screen-sharing guide covers this in detail, and Watch Together shows a notice when no screen audio was captured.
Match the symptom to the first check
| Symptom | Likely cause | First thing to check |
|---|---|---|
| No capture prompt appears. | The page is not a secure context. | Confirm the address is https:// in a desktop browser. |
| The prompt appears but capture is black. | A permission is blocked. | Allow screen recording for the site and for the operating system. |
| The microphone meter never moves. | Muted input or the wrong device. | Check the selected input and any hardware mute key. |
| Only local network addresses are found. | A firewall, VPN, or DNS filter. | Try another network or disconnect the VPN. |
| Viewers hear you but not the video. | Screen audio was not ticked. | Re-share with tab or system audio enabled. |
Checklist before your next call
- Current desktop browser, page loaded over HTTPS.
- Screen, microphone, and camera permissions allowed for the site.
- macOS Screen Recording, Microphone, and Camera enabled for the browser.
- Microphone level moves when you speak; camera preview is correct.
- Network test reaches a public relay address.
- For a live share, tick Share tab audio or Share system audio.
About this guide
This guide is maintained by the Haivix editorial team. You can read more about us and how Haivix tests its tools on our about page, and send corrections through our contact page.