Keymap Labs treats a browser as an observation layer, not direct laboratory hardware. Every diagnostic begins with a specific web-platform event or API, calculates a limited result locally and states which parts of the input path remain invisible.
Measurement boundary
The observable path begins after several physical and software layers: switch or sensor, device electronics, firmware, wired or wireless transport, operating-system input stack and sometimes a driver or remapper. The browser then applies its own mapping, privacy rules, scheduling and event coalescing before JavaScript receives data.
Our tools therefore use phrases such as “reported axis,” “delivered event” and “browser-observed rate.” They do not claim to certify USB polling, physical switch latency, internal wear or a complete keyboard matrix.
Gamepad tools use the standard Gamepad API exposed through navigator.getGamepads(). Keyboard and mouse tools use focused DOM keyboard, pointer, click and wheel events. The polling diagnostic timestamps delivered pointer movements with performance.now(). These are documented web interfaces, but implementations vary by browser and operating system.
Local processing and privacy
Raw input handling happens inside the page. Controller axes, button states, key sequences, pointer movements and click timelines are not sent to Keymap Labs. No account is required. Ordinary web-server access records are separate from diagnostic input and are covered by the privacy policy.
Because keyboard tools need only isolated codes, users are told not to enter passwords or private text. The test can listen only while the page is active and cannot read input typed in another application.
Controller center statistics
For stick drift screening, the page records axis pairs over a five-second period while the controller rests. Each sample’s radial distance is sqrt(x² + y²). The report includes average distance, maximum distance and variation. Classification thresholds are editorial screening bands, not manufacturer tolerances.
Five seconds balances usability with enough frames to avoid judging one decimal. Repeat runs remain necessary because hand contact, return direction, connection and calibration can change the observed center.
Keyboard observation
Keyboard pages distinguish physical KeyboardEvent.code from interpreted KeyboardEvent.key. Physical codes are preferred for gaming-layout discussions because they identify a position independent of the active character layout.
The active set is built from key-down and key-up events delivered to the focused window. It is cleared on focus loss to avoid displaying stale keys when the page misses a release. Browser- or operating-system-reserved shortcuts are excluded from strong conclusions.
The guided ghosting page tests selected combinations. Passing them does not prove NKRO across the full matrix. A failure is reported as an observed missing or unexpected code and should be repeated with changed press order and another environment.
Mouse click intervals
The double-click diagnostic records time between consecutive click events on the focused target. The default 80 ms threshold is a screening choice for slow deliberate clicking, not the operating-system double-click window and not a physical debounce measurement.
Intent cannot be inferred from timing. Rapid deliberate clicks can be flagged. Stronger evidence comes from repeatable close intervals while the user intentionally separates physical actions, confirmed across another connection or system.
Pointer event rate
The polling lab uses timestamps of delivered pointer-movement events. Observed rate is calculated from the count across the sampled timestamp span. Median and 95th-percentile intervals describe typical delivery and longer gaps.
Browsers may coalesce pointer movements, and main-thread scheduling, display refresh, power state and movement speed influence results. The lab is designed for relative comparisons and detection of large instability, not firmware-rate certification.
Sensitivity constants
AimCurve uses documented horizontal yaw constants to preserve modeled hip-fire cm/360. The formula, supported game and result appear together.
eDPI is displayed only as a game-specific convenience. Scoped, zoomed, FOV-relative and monitor-distance models are outside this conversion. If a game update changes input scaling, the constant and explanation are reviewed together.
Result language
We separate three levels:
- Observation: what this page received in this session.
- Interpretation: what patterns commonly mean inside the stated boundary.
- Diagnosis: a conclusion that normally requires comparison or external inspection.
Tool interfaces may provide screening tones such as tight, moderate or high, but supporting text never turns a browser sample into an unsupported hardware verdict.
Verification and corrections
Hardware-dependent behavior requires physical test devices and controlled comparisons because synthetic events cannot reproduce the complete input path honestly. Changes to calculations require repeatable checks and methodology review.
Material changes to thresholds, formulas or supported game constants are described in product updates. Research notes retain an updated date so older conclusions are not silently presented as permanent facts.
This conservative framing is part of the product. A smaller honest measurement is more useful than a larger claim the browser cannot support.