GamepadTest exists for one recurring moment: a controller is misbehaving — or you’re about to buy, return, or repair one — and you want proof, not guesswork. Connect the pad, press a button, and every input shows up live: the full button diagram, both stick scopes with trails, analog trigger levels, press counts, a resting-drift measurement with a deadzone suggestion, the browser’s snapshot update rate, and the rumble motors if your browser exposes them.

Built around honesty about limits

A web page can only measure what the browser delivers. So the tester labels its own ceilings rather than hiding them: sampling happens on the animation frame loop (~16.7ms at 60Hz), the pad’s true USB polling rate lives below the browser, and gamepad.timestamp freezing on an idle pad means the engine stopped refreshing — not that your controller died. Where a number is the browser’s view rather than hardware truth, the UI says so. The guides follow the same rule: fix steps are ordered by what actually resolves each failure, and deadzone advice comes with its cost.

Everything is local

The tester reads navigator.getGamepads() inside this tab and draws what it finds. There is no server-side component — the site is static files, so controller data can’t be uploaded even in principle. Details on the privacy page.

Who’s behind it

A small independent team builds and maintains the site, along with a family of focused hardware-check utilities on this domain. The tester and guides get revisited when browser behavior or common failure modes shift. Found a pad the tester reads wrong, or a fix step that changed? Contact — include the controller model and the browser.