Before you start
Quit every other application that could be using the camera — video call clients, streaming software, virtual camera drivers and anything that stayed running in the tray. Most operating systems give a camera to one application at a time, and a client left running in the background is the single most common reason a preview stays black.
Note which camera you intend to use. Laptops with an external webcam attached expose at least two devices, and browsers do not always default to the one you expect. If a privacy shutter or a lens cover exists, open it now so it cannot explain a black frame later.
Decide which symptom you are chasing: no permission prompt, a black preview, a picture that looks lower quality than expected, or motion that freezes. They have different causes and the checks below separate them.
Run the check
Open the webcam test and press start. Permission state is read before the request, and getUserMedia is called from the same user gesture, which is what browsers require. If the prompt never appears, the site has been blocked previously — open the permission control in the address bar, allow camera access and reload.
Once the stream opens, read the negotiated track settings rather than the constraints anyone requested. The delivered width, height and frame rate come from MediaStreamTrack.getSettings after negotiation completed, so they describe what the camera actually sent, not what an application asked for.
Check that frames are still arriving, not just that a picture exists. Frame delivery is counted through requestVideoFrameCallback where the browser supports it, and a one-pixel canvas sample flags sustained black output. A live track that delivers only black frames is a different problem from a track that stopped delivering at all.
Wave a hand in front of the lens. It sounds trivial, but it distinguishes a genuinely frozen stream from a static, badly-lit scene faster than any measurement, and it confirms the preview you are looking at is live rather than a cached first frame.
Read your result
Compare the delivered mode against what you expected, and treat any gap as a negotiation question rather than a hardware defect. A camera that opens at 640×480 when you expected 1080p has almost always been constrained by an application, by USB bandwidth or by another user of the device.
Read frame rate together with resolution. Cameras commonly trade one for the other, and many drop to 15 fps in low light because the sensor needs a longer exposure. A frame rate that falls when the room darkens is normal behaviour, not a failure.
If the picture is dim or washed out, that is exposure and white balance rather than anything the test can call a fault. Add a light source in front of you rather than behind you and re-check; back-lighting is responsible for a large share of complaints about camera quality.
Measurement limits
The browser reports the stream it receives after camera firmware, operating-system routing and application negotiation have all had their turn. It cannot read the sensor specification, so it can never confirm that a camera sold as 1080p is capable of 1080p — only that this stream is or is not delivering it.
Permission state is also partly opaque. A browser can say whether this origin is granted, denied or prompt, but it cannot see an operating-system-level camera block, which on recent Windows and macOS versions silently prevents any browser from opening the device.
Nothing observed here proves how you will look to the other participant in a call. Conferencing applications apply their own resolution caps, compression and background processing after this point.
What to do next
If the stream opens cleanly here but fails in one application, the problem belongs to that application: check its own camera selection, its resolution setting and whether it has permission at the operating-system level. Reinstalling a driver at this point is almost always wasted effort.
If the stream fails here as well, work outward: another browser, another USB port, then another computer. A camera that fails on a second machine has earned a hardware conclusion; one that works there has not.
For a call that is about to start, the fastest recovery is usually to quit every other camera application, reload the tab, and confirm a live preview here before joining. That sequence resolves most last-minute failures within a minute.
Symptom table
| Symptom | Likely layer | Next action |
|---|---|---|
| Permission prompt does not return | Site is blocked in browser settings | Allow access from the address bar and reload |
| Preview is black | Shutter, cover or stalled stream | Remove the cover and compare another application |
| Delivered mode is reduced | Constraint, bandwidth or concurrent use | Close other camera users and renegotiate |
Common questions
How do I test my webcam right before a video call?
Close other call applications, open a browser webcam test, allow access and confirm you see live motion plus a sensible resolution. The whole check takes under a minute and catches the failures that actually happen at the start of calls.
Why does my camera work in one app but not another?
Most systems grant the camera exclusively to one application. If a client is still running in the background it keeps the device, and every other application sees a black frame or an error until it is fully quit.
Is it safe to test a webcam on a website?
It is safe when the page keeps the stream local. The browser will not open a camera without an explicit permission prompt, and you can revoke that permission at any time from the address bar.