Webcam and Mic Tester

Seeing your face and a moving microphone bar proves something useful: this browser tab received a video track and an audio track. It does not prove that the picture is arriving at the rate the camera promised, that the microphone has enough headroom, or that the operating system will keep delivering audio five minutes later. Those distinctions are why this page reports the track rather than stopping at a green permission tick.

The test is deliberately split into camera-only, microphone-only, and combined modes. If a microphone is the problem, there is no reason to grant camera access. If the browser refuses a combined request, testing each input separately also identifies which half failed. A camera-only success followed by a microphone-only NotReadableErroris far more actionable than one generic “devices failed” message.

Permission is not treated as success before you decide. Until a test runs, Browser readiness says that no device has been tested. The page no longer starts with optimistic green results merely because it has not yet checked the browser. Once the stream starts, the evidence comes from the active track’s settings and events, not from a guessed default.

Browsers negotiate camera constraints. This page asks for an ideal 1280 × 720 picture at 30 frames per second, then the camera, driver, operating system, and browser settle on a configuration. The value returned by getSettings().frameRate describes that negotiated track setting. It is useful, but calling it the live frame rate overstates what was measured.

The Measured delivery tile counts frames presented to the video element through requestVideoFrameCallback(). It updates over time, so let the camera run for several seconds before judging it. A target of 30 fps and delivery that moves around 29–31 fps is ordinary timing variation. A persistent result far below the target points to a real delivery bottleneck: poor light forcing long exposure, a congested USB hub, another application sharing the camera, thermal or battery throttling, or a processor too busy to present each frame.

Delivered frames are still not an end-to-end meeting measurement. The tile does not include encoding, upload, network congestion, server processing, or decoding on another person’s computer. It answers the narrower and more useful local question: how quickly did this browser present frames from the camera it opened?

Resolution has a similar boundary. The number shown is the active track setting, not a sharpness score. A 1280 × 720 stream can look soft because the camera is out of focus, digitally cropped, dirty, or operating in poor light. Check fine detail in the preview at normal viewing distance; more pixels cannot restore detail the sensor never captured.

The microphone meter reads time-domain samples from Web Audio. RMS level estimates average signal power across the current analysis frame; waveform peak is the largest absolute sample in that same frame. Both are shown in dBFS, where 0 dBFS is the maximum representable digital sample and quieter signals are negative. Because both figures share one scale, the distance between them means something: speech often has peaks well above its average level, while steady hum has a smaller crest difference.

The previous percentage display could not support that comparison. It multiplied RMS by 180 and peak by 100, then labelled both values with the same percent sign. Worse, the RMS bar hit 100% at about −5.1 dBFS, hiding all remaining headroom between that point and clipping. The revised bar maps −60 to 0 dBFS for display, but the tiles retain the actual dBFS readings. A loud signal therefore approaches the top without pretending several distinct levels are all “100%”.

Use the numbers comparatively rather than chasing one magic target. Sit where you will sit during the call, speak normally, then speak at your loudest expected level. Normal speech should rise clearly above the idle noise floor; peaks should stay below 0 dBFS. If peaks repeatedly crowd 0 dBFS and speech sounds rough, lower the hardware or operating-system input gain. If normal speech barely moves above the floor, move closer or raise gain before relying on automatic amplification.

This is an electrical signal check, not a perceptual audio-quality score. It cannot tell whether a room is too echoey, a fan is distracting, consonants sound harsh, or a cable crackles once every few minutes. For those, use headphones and make a short recording in the application you intend to use. The page intentionally does not play the live microphone back through your speakers because that creates feedback and can make a safe test painfully loud.

Browser permission answers whether the site may request a microphone. The track’s mutedstate answers whether its source is currently able to provide media. Those are different layers. The specification describes mute as outside the web application’s control but observable through the property and its mute and unmute events.

That distinction catches failures a permission badge cannot. A physical privacy switch can stop the source. Closing a laptop lid can make its camera unavailable. An operating-system control can mute a device, and on some mobile systems a higher-priority application — an incoming phone call is the specification’s example — can take microphone access away from the browser. The Track state tile updates when the browser emits those events, so “Muted by system/device” does not get misreported as silence from the room.

An ended track is different again: it will not resume by itself. Disconnecting a USB device, revoking site permission, or stopping the source can end it. Press Stop, reconnect or re-enable the input, and begin a new test. If the track repeatedly ends with no physical change, compare another browser before replacing hardware.

The tester requests echo cancellation, noise suppression, and automatic gain control off. That makes a device check easier to interpret: a gate should not erase quiet speech, automatic gain should not make the noise floor wander, and echo processing should not reshape the waveform while you diagnose the microphone. A request is not the result, though, so the three tiles show the values returned by the active audio track.

“Not reported” is kept separate from Off. Browsers and devices expose different setting dictionaries, and an absent property provides no evidence that the processing is disabled. When a setting remains On despite the request, the microphone can still be tested; just expect its level to change as the browser reacts to your voice and background noise. Conferencing applications may request an entirely different processing profile.

Sample rate and channel count also describe the granted track, not necessarily the microphone’s native converter. The operating system may resample audio before the browser sees it. Linear sample size is shown only when reported and is labelled carefully because the specification says that constraint can only be satisfied by devices producing linear samples. Missing sample size is not a quality failure.

Target latency is equally easy to overread. It is the configuration’s target time from the beginning of one processing step until data is available to the next, and the specification explicitly says actual latency may vary. It is not measured mouth-to-ear delay and excludes the network. That is why this page no longer labels the value simply “Latency”.

A NotReadableErroris especially important not to simplify into “device busy”. The specification allows it when an operating-system, program, webpage, or hardware error prevents access, and it can also occur if the selected device becomes unsuitable between the browser’s constraint checks. Closing other meeting tabs is a good first step, not a diagnosis.

If this page works but a meeting service does not, keep the successful result as a boundary: the browser and device can produce media in at least one origin. Re-select the same labelled input inside the service and check that site’s permission. For output trouble rather than microphone input, use the separate Speaker Tester to identify left/right channel and playback problems without reopening the camera.

This page cannot test a conferencing service’s servers, account policy, virtual background, recording, screen sharing, network path, or the device chosen inside that service. It does not measure lip sync or mouth-to-ear delay. It cannot guarantee that an input which works now will remain connected after a cable is moved or another program takes exclusive control.

It also cannot enumerate a detailed hardware inventory before permission, bypass an operating-system privacy decision, or reveal why a browser intentionally redacted an OverconstrainedError’s constraint name. Those limits reduce fingerprinting and prevent a page from learning about nearby equipment without a user decision.

The useful promise is narrower: the tester requests temporary tracks, shows the frames and samples available to this tab, measures what the browser can measure honestly, and reports unknown values as unknown. No media file is created, and the camera and microphone streams are not uploaded to ToolMintX. Press Stop when finished so the tracks are ended immediately rather than waiting for the tab to close.