Before a video call — which tools to run (screen, camera, microphone)

Last reviewed 2026-05-03. Five minutes before a Zoom / Teams / Google Meet call is the wrong moment to see that your webcam shows a black screen, your microphone is muted at the OS level, or your screen has a stuck pixel right where the speaker's slides will appear. This guide is the short, in-priority-order checklist of which checks to run, what each one catches, and which tool to start with. Each step has a tool link to the matching browser test on this site — nothing to install, no account, no upload. The whole sequence runs in about five minutes.

Step 1 — Camera test (60 seconds)

The single most-common pre-call failure is "the camera works in the OS but Chrome cannot see it." That happens because a previous app (Slack, OBS, FaceTime, the OS camera privacy panel) still holds the device handle, or the browser was denied camera permission earlier and the user has forgotten. The browser-side camera test catches both within seconds.

Open the camera test, click Start Camera, and grant the permission prompt. A live preview should appear within two seconds with the resolution shown next to the picture. If the preview is black, the camera is busy in another app — close Slack / Teams / Zoom desktop clients and retry. If the permission prompt does not appear, the browser already remembers a deny — click the camera icon in the address bar to grant it. If the preview is upside down or mirrored, that is a driver / browser quirk you will live with for the call (most conferencing apps mirror the local preview deliberately).

What this step does not catch: the quality of the picture (lighting, focus, white balance) or the audio side. The microphone is checked separately in step 2 because the failure modes are different and many users have working camera and broken mic at the same time.

Step 2 — Microphone test (60 seconds)

Microphone failures fall into three families: the OS does not see the mic at all (driver / cable / Bluetooth pairing dropped), the browser was denied permission, or the OS sees it but routed it to the wrong device (the laptop array mic instead of the headset, or vice versa). The browser-side microphone test exposes all three.

Open the page, allow the permission, and speak normally. A live volume meter should react to your voice within half a second. If the meter does not move, switch input devices in the OS sound panel — the headset may not be the default. If the page says "no microphone detected," the OS lost the device entirely; reconnect the cable / re-pair the Bluetooth headset, then refresh the page. If the meter moves but is too quiet (peaks below half), the OS input gain is low — raise it before the call rather than during it.

This step does not catch network-level audio issues (VoIP packet loss, jitter) or the conferencing app's own echo / noise-suppression filters. Those only show up inside the actual conferencing app and are best confirmed with a test call to a colleague.

Step 3 — LCD test (60 seconds)

You will be staring at slides, code, or a face for the next thirty to sixty minutes. A stuck pixel in the middle of the screen is harmless mathematically but distracting visually, and a stuck pixel directly on top of someone's nose during the call is the kind of detail that pulls focus from what is being said. The browser-side LCD test cycles the screen through solid red / green / blue / white / black in about a minute and exposes panel-level defects: dead pixels (always black), stuck pixels (locked to one color), uniformity issues (patches lighter or darker than the rest), and backlight bleed (corner glow on a black field).

If the LCD test surfaces a defect, you have two choices: position the conferencing app's window so the defect sits outside its visible area (works for one or two pixels in a corner), or accept it for this call and run the warranty-prep workflow in the companion how to test for dead pixels before returning a monitor guide afterwards.

This step does not catch signal-path problems (cable, refresh-rate negotiation, EDID handshake) — for those, see LCD test vs display test vs monitor test for which test catches what.

Step 4 — Keyboard test (90 seconds; only if you will type)

Skip this step if you are joining as a listener. Run it if the call involves typing — an interview where you take notes live, a code-share session, a Q&A you will moderate. The keyboard test visualises every key press and confirms that no key is mis-mapped or stuck. The most common failure is one key that registers as a different key (a sticky-keys leftover from the OS), or a key that does not register at all (mechanical-switch failure). Either is worth catching before you mistype the candidate's name in front of them.

This step does not catch software-side keyboard layout issues (the OS thinks you are using a US layout but the physical keyboard is UK) — the test reads physical scan-codes, not the resulting characters. If the test passes but the wrong characters appear in the conferencing app, change the keyboard layout in the OS settings.

Pre-call checklist (printable)

1. Camera — camera test → live preview within 2 s; correct resolution; permission granted in the browser.
2. Microphone — microphone test → volume meter reacts to your voice; correct input device selected in the OS.
3. Screen — LCD test → no stuck / dead pixels in the area where the conferencing window will sit.
4. Keyboard (if typing) — keyboard test → every key registers correctly; no mis-mapped or stuck keys.
5. Lighting (visual judgement; no tool needed) — light source in front of you, not behind; no bright window in the camera frame.
6. Notifications — OS Do-Not-Disturb on; close Slack / email / messenger desktop clients to avoid a popup mid-share.

FAQ

How long does the full checklist take?
About four minutes if you skip step 4 (keyboard), about five with step 4. Each tool runs in a single browser tab; you can leave them open and re-run any step that fails before the call starts.

Can I run the checklist on my phone?
Camera test and microphone test work on a mobile browser (the same browser permissions apply). The LCD test runs but the result is less useful on a phone — you are unlikely to be presenting from a phone screen. The keyboard test does not apply to a touchscreen.

What if the camera works in the test but not in the conferencing app?
The conferencing app most likely has its own camera-permission prompt that you have not yet answered, or it is bound to a different camera (a USB cam vs the laptop's built-in). Inside the conferencing app, open the audio / video settings and select the camera explicitly. If it still does not show, the conferencing app's desktop client is using the camera; refresh the browser tab where you ran the test — whichever app holds the device handle wins.

What if the microphone test passes but the conferencing app says "your audio is muted"?
That is the conferencing app muting at its own layer (the host muted you, or the app is the "audio off" default for guests). Unmute inside the app; the OS-level mic and the app-level mic are independent. The companion guide how to check webcam and microphone before an interview walks through the layered permissions in more detail.

Why run the screen test — isn't a stuck pixel just cosmetic?
For a one-on-one call, yes, you can ignore it. For a presentation to a group or a recorded interview, a stuck pixel is the kind of detail that ends up on a screen-share recording forever. Catching it before the call lets you reposition the window or pick a different monitor.

What if a step fails — can I still take the call?
Camera fail → switch to audio-only with a disclaimer. Microphone fail → reschedule, or join from your phone for audio while presenting from the laptop. Screen fail → reposition the conferencing window away from the defect; call goes ahead. Keyboard fail → switch to a USB keyboard, or take the call as a listener and not a typer.

Related

• Camera Test — the in-browser webcam preview, resolution, and capture tool.
• Microphone Test — the in-browser microphone level meter.
• LCD Test — the in-browser full-screen color cycle for stuck / dead pixels.
• Keyboard Test — the in-browser per-key visualiser.
• LCD test vs display test vs monitor test — companion disambiguator for screen-related symptoms.
• Camera test vs webcam test vs camera quality — companion disambiguator for camera-related symptoms.
• How to check webcam and microphone before an interview — interview-specific deep dive.
• How to test for dead pixels before returning a monitor — warranty-prep workflow if the LCD test surfaces a defect.
• Device test checklist for remote work — the broader weekly-cadence checklist.