Measurement principle: browser-visible evidence
Every GearCheck Lab diagnostic starts by identifying the browser API that can expose relevant device behavior. Controller tools use the Gamepad API. Keyboard and mouse tools use browser input events. Audio output tools use Web Audio. Camera and microphone tools use MediaDevices and Web Audio analysis. Display tests use controlled visual patterns rendered by the browser.
This creates a practical boundary: the site can measure what reaches the browser, but it cannot automatically prove what happened at every deeper layer between the physical device and the webpage.
When a value is described as an update rate, input level, frame rate, axis value or similar measurement, it should be read as a browser-level observation unless the page explicitly states otherwise.
Controllers
Controller diagnostics read axes, buttons, mapping, connection state and timestamps reported by the Gamepad API. Stick drift tests calculate distance from the reported neutral point. Deadzone pages compare live stick magnitude with a user-selected threshold. Trigger tests inspect browser-reported analog button values. Polling tests count fresh browser-visible timestamp changes over a rolling time window.
Controller IDs, axis order and button mappings can differ on non-standard devices. Wireless transport, firmware, operating-system drivers and browser behavior can all affect what reaches the page.
Keyboard and mouse
Keyboard rollover tools count simultaneously held keys that generate browser key events. A missing event is useful evidence, but not proof by itself of hardware ghosting because browser or operating-system shortcuts can intercept combinations.
Mouse polling pages count browser-delivered movement events. This is useful for comparing settings or connections under similar conditions, but it is not guaranteed to equal the raw USB report rate measured by specialized hardware or kernel-level tools.
Display tests
Solid-color patterns help users visually inspect for dead/stuck pixels and obvious uniformity issues. Gradients can reveal visible banding. High-frequency checker patterns can expose scaling or sharpness differences.
These are visual screening tools. Browser rendering, color management, GPU output, panel processing, viewing angle and room lighting all affect the result. GearCheck Lab does not replace a colorimeter, photometer or manufacturer pixel-defect standard.
Audio output
Audio tests generate controlled digital tones with Web Audio and route them through left, right or centered stereo panning. The digital oscillator frequency is known to the Web Audio graph, but acoustic output level and frequency response are not calibrated.
Speaker response, headphones, amplifiers, operating-system volume, equalization, room acoustics and human hearing all influence perceived loudness. Audio pages are equipment checks, not hearing tests.
Camera and microphone
Webcam tools display the local MediaStream and report track settings such as resolution and frame rate when the browser provides them. Observed frame callback rates can be shown where the browser supports that API.
Microphone tools calculate relative signal energy from short waveform buffers. The level meter is useful for detecting input and comparing relative levels within a session, but it is not a calibrated sound-pressure meter or studio dBFS meter.
How result labels are chosen
Where a tool uses PASS, WARNING or FAIL-style language, the label is intended as a practical interpretation of that specific browser measurement. It is not a manufacturer warranty verdict. Thresholds are chosen to make the diagnostic actionable and are described on the page where they matter.
We avoid using one universal threshold across unrelated devices. For example, controller drift, trigger range, microphone level and mouse event frequency are fundamentally different measurements. A good result is judged in context.
RepeatabilitySuspicious results should be reproducible, not based on a single transient sample.
ComparabilityWhen comparing settings, use the same browser, device, motion pattern and test duration where practical.
Layer awarenessA browser result should not be presented as a lower-level measurement unless the browser actually exposes that layer.
Accuracy and uncertainty
Browser APIs are excellent for interactive troubleshooting, but they are subject to scheduling, event coalescing, device mappings, permission rules and platform differences. GearCheck Lab therefore favors ranges, trends, repeated samples and direct raw values over false precision.
When a tool cannot distinguish between several plausible causes, the text should say so and recommend comparison steps instead of assigning a definitive fault.
Verification before publishing
Public tools are expected to have working interaction, unique purpose, valid metadata, responsive behavior, clear permission or error states where relevant, and explanatory content covering interpretation and limitations. Site changes are versioned and production deployments are checked for successful build status.
Known limitations should be visible to users rather than hidden in internal documentation.
Recommended troubleshooting pattern
- Run the relevant test under normal conditions.
- Repeat a suspicious result several times.
- Change one variable at a time: USB vs Bluetooth, another port, another browser, another device setting or another computer.
- Use a related GearCheck Lab tool to narrow the symptom.
- Confirm important findings using the manufacturer's own utility, operating-system diagnostics or professional measurement equipment when necessary.