Methodology

Testing Methodology

Last updated: August 2026

How Browser-Based Testing Works

GamepadTools tools use browser APIs and browser-observable signals to perform their tests. The specific APIs and measurement methods vary by tool — we don't claim every tool works the same way. Below is what each group of tools actually uses, verified against the current implementation:

  • Gamepad tools (Gamepad Tester, Joystick Test, Dead Zone Test, Polling Rate Check, Latency Test, Vibration Check, Battery Check) read controller state through the Gamepad API, polled via requestAnimationFrame.
  • Vibration Check, and the vibration indicator on Gamepad Tester and Battery Check, use the Gamepad API's haptic actuator interface where the browser and controller combination supports it.
  • Battery Check additionally uses WebHID, available only in Chromium-based browsers (Chrome, Edge, Opera).
  • Mouse tools (DPI Analyzer, Click Speed Test, Double Click Test, Mouse Button Check, Mouse Polling Rate, Reaction Time Test) read standard mouse events (mousedown, mouseup, click, mousemove) with high-resolution timestamps via performance.now(). Mouse Polling Rate additionally uses Pointer Lock to read raw, uncapped movement.
  • GPU Check uses WebGL and the WEBGL_debug_renderer_info extension to identify your graphics hardware.
  • Frame Rate Test and Refresh Rate Test use requestAnimationFrame and performance.now() to measure rendering intervals.
  • Resolution Check reads window.screen and your device pixel ratio directly.
  • Screen Bleeding Test is a guided visual test using full-screen color panels for you to inspect — it doesn't perform an automated measurement.

We only list APIs that the current implementation actually uses.

What Our Tools Measure

Concretely:

  • Latency Test measures the time between an input event firing and the page registering it, using performance.now() timestamps. This is a browser-observed measurement, not a measurement of the complete input-to-display chain (see "What Our Tools Do NOT Measure" below).
  • DPI Analyzer estimates DPI by measuring how far your cursor travels on screen relative to a calibrated physical distance you provide.
  • Mouse Polling Rate estimates the browser-observed mouse input/report rate, while Controller Polling Rate estimates the browser-observed controller input update rate. Neither is a direct read of the device's internal USB or firmware polling schedule.
  • Click Speed Test and Double Click Test rely on click-event timestamp deltas.
  • Frame Rate Test counts actually rendered frames per wall-clock second.
  • Refresh Rate Test infers your monitor's refresh rate from consistent frame-timing intervals measured over several seconds.

What Our Tools Do NOT Measure

This matters as much as what they do measure. Browser-based testing cannot observe:

  • total end-to-end input latency, including the display's own added lag — our latency figures reflect browser-observed input timing, not the complete input-to-photon chain;
  • the exact internal polling schedule of a USB device at the hardware/firmware level;
  • the electrical characteristics of your hardware;
  • the complete physical health of your GPU (only what's exposed via WebGL);
  • exact sensor firmware configuration inside a controller or mouse.

Where a specific tool has a limitation beyond this general list, it's stated on that tool's own page.

Browser and OS Effects

Because every tool depends on the browser to report accurately, results can vary with: which browser you're using, your operating system, device drivers, your connection type (wired vs. wireless), background load on your device, power-management settings, your specific hardware, and how a given browser implements the underlying API. This is normal and expected — it's why we describe our tools as diagnostic aids rather than certified test equipment.

Testing and Validation

Tools are reviewed against their underlying browser APIs and expected behavior before publishing. Where we have personally tested a tool with physical hardware, those tests are treated as first-hand observations and documented separately from information derived from technical specifications or browser documentation. We don't publish a list of "tested controllers" unless that list reflects hardware that was actually tested — we'd rather have no list than an invented one.

Tool-Specific Methodology

For the full detail behind any individual tool, visit that tool's page directly — each one explains its own inputs, outputs, and known limitations:

Keeping This Page Current

Browser APIs change over time. When an update affects how a tool reads data, we update both the tool and this page to match.