Device Bench

Device test · Game input

Gamepad Tester

Press every button and move every stick on any game controller and watch each one register live. Then measure what a live board can only hint at: resting stick drift over a timed sample, the point where each axis first registers input, analogue trigger travel, and whether your browser can drive the rumble motors. Everything runs in your browser, and nothing you press leaves this device.

Statuswaiting Controller— Buttons— Axes— Driftnot run Deadzonenot run Rumble—

Connect a controller (USB or Bluetooth) and press any button on it to wake it up — browsers only expose a gamepad to a page after its first button press.

Nothing has been measured yet.

Measure drift takes a five-second sample of every axis with your hands off the sticks and reports the resting offset per axis against a ±0.05 settled band and a ±0.10 drift threshold. Deadzone probe records a 1.5-second baseline, then watches a slow sweep for the first value that clears each axis's noise band. Rumble test asks your browser to play a half-second effect and reports exactly what it did with the request. Results appear here with the window they were measured over.

How this test works

Every controller you connect is exposed to this page through the browser's Gamepad API. Each pad reports an identity string, a mapping type, an array of buttons, and an array of axes. Buttons carry two readings: a digital pressed flag and an analogue value from 0 to 1, which is how triggers report partial pulls. Axes are the sticks, reported from −1 to +1 in each direction, where 0 is perfectly centered. The board shows all of it live — each button lights as it registers, the fill bar along its bottom edge shows its analogue value, each axis row plots the live stick position against a center mark, and any button ever seen reporting a partial value earns a trigger-travel row with its live reading and its furthest travel. Any pad the browser exposes is read the same way — an Xbox controller, a PS4 or PS5 DualSense pad, or a generic USB joystick — and a pad that declares the standard mapping has its buttons labelled A, B, X, Y, LB, RB, LT, RT, Back, Start and the two stick clicks; anything else keeps its bare index rather than being mislabelled.

Three measurements sit on top of that live view. The drift sample reads every axis for five seconds while you keep your hands off the sticks, then reports each axis's mean resting value, its peak-to-peak spread, and the number of readings behind those figures; a mean within ±0.05 is settled, beyond ±0.10 is drift. The deadzone probe first takes a 1.5-second baseline to learn each axis's resting value and noise band, then watches a slow sweep and records the first reported value that clears that band — the gap between the two is what the pad or driver is swallowing before the browser sees anything. The vibration check calls playEffect on the pad's vibration actuator for half a second and reports what the browser did with the request. The page polls with requestAnimationFrame, re-reading navigator.getGamepads() on every frame because some browsers return an immutable snapshot rather than a live object, and polling stops entirely when the last pad disconnects.

The limits are set by the API, not by the hardware, and this page states them rather than papering over them. Browsers hide gamepads until you press a button, so a silent controller is invisible by design. Nothing here sees physical stick position: every figure is a reported value, so a deadzone is visible only as a gap in the numbers, never as a physical distance. Some pads and drivers snap their own center to exactly zero, in which case an offset smaller than that snap cannot be measured here at all — that is reported as unmeasurable rather than as a clean pass. Sampling is tied to the display refresh, so a throttled background tab produces a withheld result instead of a low-confidence one, and a stick touched mid-sample discards the sample. A rumble effect the browser accepts confirms only that the request reached the actuator; whether the motors moved is something no part of the API reports.

Running a controller drift test

Most people arrive at a gamepad tester because a camera creeps or a character walks on its own, which is a joystick drift problem and a measurable one. Do it in this order. Connect the pad and press a button so the browser exposes it. Put the controller down on a flat surface, hands completely off — resting a thumb on a stick is the single most common way to invalidate the result. Press Measure drift and wait out the five seconds. Read the per-axis rows: the resting value is the number that matters, and the peak-to-peak spread beside it tells you whether the error is a steady offset or a jittery one.

A steady offset past ±0.10 with a small spread points at a worn or off-center sensor. A small offset with a large spread points at contamination — the values wander rather than sit. Those two point at different fixes, which is why both numbers are reported rather than one verdict. If the row says the pad reports exactly 0.000 on every reading, its firmware or driver is snapping the center, and no browser-side test can see through that; judge it in a game with the deadzone turned down instead.

Then run the Deadzone probe to see how much travel your pad discards before it reports anything at all — a large pad-side gap explains why a small measured drift never shows up in games, and a gap near zero explains why a small one does. Write your numbers down, apply one fix at a time, and re-measure the same way afterwards; that comparison is the whole point. The stick drift guide covers what causes each pattern and which fixes actually last.

Frequently asked questions

Why doesn't my controller show up?
Press a button on the controller first — browsers deliberately hide gamepads from pages until they receive real input, as a fingerprinting protection. If it still fails to appear, confirm the controller is paired or plugged in and recognized by your operating system, click once on this page so the tab has focus, and close any game or remapping software (Steam included) that may have exclusive hold of the controller.
What does the drift test measure, and what counts as drift?
It samples every axis for five seconds with your hands off the sticks, then reports the mean resting value, the peak-to-peak spread across the window, and how many readings it collected. A healthy stick settles within about ±0.05 of zero. Between ±0.05 and ±0.10 is early wear that most in-game deadzones still hide. Consistently beyond ±0.10 is drift, and games will see movement you never made. If a stick moves during the window the sample is discarded instead of reported, and if the browser throttles polling below 20 readings a second the result is withheld — a number measured under those conditions would not mean what it says.
What does the deadzone probe actually measure?
Reported values, not physical stick travel. The browser cannot see where your stick physically sits, so nothing here can be given in millimeters or degrees. The probe first records a 1.5 second baseline with the sticks still, which gives each axis a resting value and a noise band; then, as you sweep slowly from center to the limit, it records the first value that clears that band. A large gap between the two means the pad or its driver ignores the first part of travel before the browser ever sees it. A gap near zero means values run continuously down to the noise floor, so any dead area you feel in a game is being applied by the game. An axis you never move is reported as unmeasured, never as zero.
Why do my triggers show up as axes, and why does the controller name look different in every browser?
Controllers describe themselves to the browser however their firmware and driver choose, and each browser formats that description differently — the same pad can be one name string in Chrome and another in Firefox, with vendor and product IDs on one platform and a plain product name on another. Pads that use the standard mapping report 17 buttons in a fixed order, with the triggers as analogue buttons 6 and 7. Non-standard pads — flight sticks, wheels, adapters, older or third-party controllers — may report triggers as extra axes, order buttons differently, or expose more controls than they physically have. That is a mapping difference, not a fault: press each control and watch which element responds.
Why doesn't the vibration check work, and what does “accepted” mean?
The controller vibration test asks the browser to play a half-second effect on the pad's vibration actuator, and support for that is patchy. Chromium-based browsers expose vibration for most Xbox and PlayStation pads, Firefox and Safari often do not, and a controller connected over Bluetooth can lose rumble even when it works over USB. If the buttons stay disabled, your browser is exposing no vibration actuator for this pad — that says nothing about whether rumble works in actual games. When the effect does run, “accepted” means the browser took the request and reported it complete after half a second. It does not mean the motors physically moved: nothing in the API reports that, so only you can confirm it. Trigger rumble is offered only when the pad advertises support for it.

Related tools