Screen Share Test

What Screen Share Test helps you do

Before a meeting, demo, or recording, check whether your browser, microphone, camera, and network are actually ready to share your screen. Each check runs in your browser and shows a clear pass, warning, or failure so you know what to fix before you are on the call. It is a preflight test, not a meeting client.

All checks run in your browser. Device streams stop when you select Stop, and nothing is recorded, uploaded to Haivix, or stored.

How it works

The page inspects the browser's capabilities, then calls the same media and WebRTC APIs a meeting app uses. Device checks open a temporary stream and stop it when you finish. The network check gathers ICE candidates against a public STUN server to confirm that the browser can reach a relay-style address; it does not contact Haivix.

How to use Screen Share Test

1. Review the browser readiness list, which checks HTTPS, capture, WebRTC, and codec support automatically.
2. Test screen capture, the microphone, and the camera to confirm each device works and grant access.
3. Run the network test, then use the results to fix anything shown as a warning or failure.
4. Stop the test so the device streams are released before joining the real call.

When to use it

• Confirm your setup works before joining a call or starting a screen share.
• Diagnose why a screen share, microphone, or camera is not working.
• Check camera and microphone permissions after changing browser or system privacy settings.
• Test a new laptop before an important presentation.
• Check a locked-down work machine before a client demo.
• Confirm that a VPN or firewall is not blocking WebRTC.

When not to use it

• Do not use it to test a specific meeting vendor's servers or account.
• Do not treat a pass as a guarantee that a particular call will connect.
• Do not run device tests on a machine you do not have permission to use.

Example

A presenter's camera works in the test but the network check warns that no STUN candidate was reachable. The VPN is the likely cause, so they disconnect it before the call. The screen share then connects on the first attempt instead of failing in front of the audience.

What you can do with Screen Share Test

• Check HTTPS, screen capture, WebRTC and codec support automatically.
• Test a screen, window or tab capture and confirm the picker works.
• Test the microphone and camera and grant device permission.
• Run a network reachability check against a public STUN server.
• Show pass, warning or failure for each check.
• Stop every device stream when the test is finished.

Example: preflight a client demo

Open the test on the machine you will use, allow the browser permissions, and run each device check. A failed screen test is much easier to fix now than two minutes before the call.

Run the network check and read the warning text if it fails. A blocked STUN path often points at a firewall or VPN, not at the meeting service itself.

Close the test, reopen the meeting, and share a window rather than the whole desktop if the client only needs to see one app.

What to know before you start

• The device tests need a desktop browser and permission to use your screen, microphone, or camera.
• The network test checks STUN reachability, not a specific meeting service.
• A passing result confirms a capability exists; it cannot guarantee a particular call will connect.
• The test does not measure bandwidth, jitter or packet loss over a full call.
• It does not sign in to a meeting platform or test that platform's account settings.

Common mistakes

• Skipping the network check because the camera and microphone pass.
• Blocking the browser permission prompt and assuming the device is broken.
• Testing the wrong microphone or camera and not noticing the device name.
• Leaving another app in control of the camera during the test.
• Treating a passing preflight as a guarantee for every meeting platform.

Troubleshooting

If the camera or microphone check fails, check the site permission, the OS privacy setting, and whether another app is using the device.

If screen capture fails, confirm that the browser supports the Screen Capture API and that the page is served over HTTPS.

If the network check warns, try without the VPN, allow UDP traffic, or test on a different network. A restrictive firewall can block the relay path.

If a device appears in the list but produces no signal, select another device and test again before assuming the hardware is broken.

If the page reports an unsupported codec, update the browser or try a different one; the meeting service may still work with a fallback codec.

Related standards and documentation

• WebRTC and the ICE/STUN framework describe the network path tested here.
• The Screen Capture API defines the browser surface picker.