Test your webcam, microphone and keyboard before a call, an exam or after a spill

Five minutes before a job interview, an exam, or a call with forty people on it is a bad time to discover that the camera is showing a black rectangle or that nobody can hear you. It is also a bad time to install anything. Every one of these checks can be done in a browser tab, because the same APIs that let a video-call site use your camera and microphone let a test page show you exactly what they are producing. This guide covers what to check and in what order, how to read the results, what the permission prompts actually mean, and how to tell a broken device from a busy one — using the webcam, microphone and keyboard testers here, none of which record or transmit anything.

Three gates, and why a device can be “working” and unavailable

Before any test tells you something useful, understand what stands between a page and your hardware. There are three independent gates:

1. The operating system. macOS and Windows both keep a per-application list of what may use the camera and microphone. The browser is one application on that list. If it is switched off there, no website can ask.
2. The browser, per site. A permission prompt, remembered per origin. This is the one people recognise, and the one you can reset from the icon in the address bar.
3. The hardware itself. Another program may be holding it. This is the most common cause of a camera that works in one app and not another.

A fourth requirement is invisible: the page must be on a secure connection. Browsers only expose camera and microphone access over HTTPS (or on localhost), so a test page delivered over plain HTTP simply cannot ask.

One consequence worth knowing: until you grant permission once, the browser deliberately hides your device names, showing generic labels instead. That is an anti-fingerprinting measure — the list of your peripherals is surprisingly identifying. Grant access once and the real names appear.

Camera: check the numbers, not just the picture

Open the webcam test, allow access, and you get a live preview plus what the camera is actually delivering: its label, the resolution, the frame rate and the aspect ratio. Those numbers are the useful part, because “the camera works” and “the camera is producing what I expect” are different statements.

• Resolution lower than you paid for. A 1080p webcam reporting 640×480 usually means another application already constrained it, or the driver fell back. Restarting the browser after quitting other video apps normally restores it.
• Frame rate in single figures. Nearly always light. Webcams drop their frame rate in dim conditions to keep the exposure long enough. More light, or a lamp behind the screen, fixes what looks like a stuttering camera.
• Several devices in the list. Laptops with an external monitor, or with virtual-camera software installed, often have three or four. Switch between them here to find out which is which — the picker restarts the stream on the one you choose.
• The mirror toggle. Your preview is mirrored by default because an unmirrored view of yourself is disconcerting. It affects only the preview, never what a call would send.

If it fails, the message tells you which gate closed. A denial says access was refused — reopen the permission from the address bar. “No camera was found” means the browser sees no device at all, which points at the OS or a hardware switch. Any other error is passed through verbatim from the browser, and the common one there is the camera being held by another application: close the video-call app that is still running in the tray and try again.

Microphone: a meter, then a recording

The mic test does two things, and the second one is the one that actually proves anything. A live level meter responds to your voice immediately — if the bar moves, audio is reaching the browser, which rules out most of the stack in one second. Then record a five-second clip and play it back, because only your own ears can tell you the difference between working and good. Clipping, a hum, a fan, a room echo, that hollow underwater character of an over-processed headset: none of it shows up on a meter.

What the results tell you:

• No movement at all. Wrong input device selected, hardware mute switch engaged (many headsets have one on the cable), or the OS gate closed. Use the device picker to try each input in turn.
• Movement but nothing on playback. That is an output problem, not an input one — check the speaker volume and the output device, which is frequently still set to a headset you unplugged.
• The meter pinning at the top. Input gain is too high and your voice is clipping. Lower the input level in the OS sound settings rather than moving further from the microphone.
• Muffled, thin, or robotic playback on a Bluetooth headset.Expected, and worth understanding: when a Bluetooth headset’s microphone is active, the connection drops from a high-quality one-way audio profile to a low-bandwidth two-way call profile. Music sounds worse the moment the mic engages. A wired or USB microphone avoids the trade entirely.

The recording stays in the page for you to play back and disappears when you leave — nothing is uploaded, and nothing is written to disk unless you save it.

Keyboard: dead, stuck, ghosting or just a different layout

The keyboard tester draws a keyboard and lights each key as you press it, keeping two separate marks: which keys are currently held and which you have pressed at least once. That second set is what makes a systematic check possible — work along each row and any key that never lights is the problem.

The four faults, and how each looks:

• Dead key. Never lights, however hard you press. If its neighbours work, the switch or that part of the membrane has failed.
• Stuck key. Stays lit after you let go, or lights on its own. Usually debris or dried liquid. It also explains bizarre behaviour elsewhere — a stuck modifier makes every other key do something unexpected.
• Chatter. One press registers twice. Watch the last-key panel while tapping deliberately.
• Ghosting. Hold three or four keys in the same area and one of them fails to appear. This is a wiring limitation of cheaper keyboards rather than a fault, and it matters for gaming and fast typing.

The tester also shows the raw event for the last key: the character produced, the physical key code, the legacy key code, the location (left or right modifier) and whether the event was an auto-repeat. That distinction between the physical key and the character it produces is the answer to a whole class of confusion — if pressing the key next to Enter produces # when you expect @, the hardware is fine and the operating system is set to the wrong keyboard layout.

Two practical details. Ordinary presses are intercepted so they register instead of acting — F5 lights up rather than reloading the page, and Space does not scroll — while modifier combinations stay usable, so you can still refresh or open devtools. And on Chromium browsers there is a full-capture mode that goes fullscreen and takes over even the keys the operating system normally owns, so Escape, Alt and the Windows or Command key can be tested too. Leaving fullscreen releases it. The numeric keypad is hidden on narrower screens, where laptops usually have none, and appears the instant you press a real keypad key.

Nothing you type is recorded or sent anywhere — which is worth stating plainly for a tool that watches every keystroke. It exists entirely in the page.

A five-minute pre-call routine

1. Quit other video apps first.Not minimise — quit. This alone resolves the majority of “my camera stopped working” reports.
2. Camera: preview, and check the resolution and frame rate are what you expect. Add light if the frame rate is low.
3. Microphone: watch the meter, then record and play back five seconds. Listen for the room, not just for yourself.
4. Output: confirm you can hear the playback through the device you will actually be listening on.
5. Keyboard, if you are about to be typing under pressure — an exam, a live-coding interview.
6. Then open the meeting app,knowing that if it cannot see a device, the problem is that app’s permission and not your hardware.

After a spill

Speed matters more than technique. Power off immediately, unplug, and turn the machine upside down so liquid drains away from the board rather than into it. Leave it that way for a couple of days — genuinely a couple of days, not a couple of hours — before trying to power it on. Do not use a hairdryer, which pushes moisture further in. Sugary and alcoholic drinks are much worse than water, because the residue keeps conducting after it dries; those usually need a keyboard replacement or professional cleaning.

When it powers on again, the tester tells you what survived: work through every key, note the ones that do not light, and you have a factual list to take to a repair shop rather than “some keys feel odd”. A USB keyboard is a fine stopgap while you decide.

When you want to record rather than test

If the goal is to capture what is on screen — a bug you need to show someone, a walkthrough, a demo — the screen recorder here captures a screen, a window or a single tab, optionally mixing in your microphone so you can narrate. It records to a file on your machine with no watermark and no time limit, and like everything else on this site it runs in the page rather than uploading your screen to a service.