probekits

How to test a controller before you blame the game

Before blaming a game for ignoring a button, it is worth finding out what the controller is actually reporting. This guide walks through exposing the pad to a browser, sweeping every control systematically, and separating a hardware fault from a binding problem.

Updated 2026-09-084 min read5 steps

Before you start

Connect the controller the way you normally use it, then decide whether the complaint is about a button, a stick, a trigger or the connection itself. Wireless pads add an entire class of intermittent symptoms, so if the fault is dropouts, try the cable first — it is a one-minute test that eliminates the most likely cause.

Close other applications that grab controllers: game launchers, remapping tools such as vendor configuration software, and anything providing virtual controller emulation. These can capture input exclusively or rewrite it before the browser sees anything.

Charge the pad or replace its batteries. Low power produces exactly the pattern people describe as failing hardware: dropped inputs, sticks that stop responding at the extremes, and disconnects under load.

Run the check

Open the gamepad test and press any button. Browsers deliberately hide connected gamepads until the user presses a control, so an empty screen before your first press is a privacy feature rather than a missing device. Once the pad is exposed, everything else becomes readable.

Sweep the face buttons, shoulder buttons, D-pad and stick clicks in order, watching that each one changes state and returns to rest. Working in a fixed order matters, because it is easy to convince yourself you tested a button you skipped.

Move each analogue stick slowly around its full circle, then release it. Axes are reported to two decimal places, so you can watch whether the stick reaches its extremes in every direction and whether it returns cleanly to centre. A stick that reaches only 0.85 in one direction has a mechanical or calibration problem.

Squeeze both triggers slowly. Analogue triggers should sweep smoothly from 0 to 1 rather than jumping; a trigger that reports only its endpoints is behaving as a digital button, which some pads and some browser mappings do deliberately.

Finally, leave the pad completely untouched for ten seconds and watch the resting axis values. This is the drift check, and it needs your hands off the controller entirely to be meaningful.

Read your result

A control that never changes value in the browser is a strong hardware signal, because the page reads the pad through the operating system's own driver with no game logic in between.

A control that works here but not in a game is a binding, profile or remapping problem in that game. This is by far the most common outcome, and it saves people from replacing perfectly healthy controllers.

An unlabelled or missing control is usually a mapping gap rather than a fault. Browser gamepad mapping follows a standard layout, and vendor-specific extras — paddles, touchpads, gyros — often have no standard slot to appear in.

Measurement limits

The page samples the Gamepad API once per animation frame, so on a 60 Hz display it reads the pad sixty times per second. That is a page sampling rate, not the controller's report rate, and no browser exposes the latter.

A browser cannot read battery level reliably, cannot access rumble on every pad, and cannot see firmware version or calibration data. It sees the mapped button and axis values the driver publishes.

Disconnects are reported as events but not explained. The page can say the pad went away; it cannot distinguish a flat battery from a radio problem or a loose cable.

What to do next

A control that fails in the browser, on more than one machine, is a hardware conclusion. Many pads have replaceable modules and many are covered under warranty, so it is worth checking before buying a replacement.

A control that passes here and fails in one game belongs to that game's input configuration. Reset its bindings, disable any remapping layer, and check whether it is reading the pad through a different API than the browser does.

Intermittent dropouts that disappear on a cable are a wireless problem: interference, distance or battery. Moving the receiver closer or removing USB 3 devices near it resolves a large share of these.

Symptom table

SymptomLikely layerNext action
A button never changesSwitch, ribbon or mapping gapConfirm on a second machine before replacing
Trigger jumps 0 to 1Digital mapping or worn potentiometerSqueeze slowly and watch for intermediate values
Pad disconnects under loadBattery, interference or cableRepeat the run on a wired connection

Common questions

Why does my controller not show up until I press a button?

Browsers hide connected gamepads until a user interaction, which prevents pages from silently fingerprinting your hardware. Press any button once and the pad becomes readable immediately.

Can I test a PlayStation or Xbox controller in a browser?

Yes. Any pad exposed through the Gamepad API works, which covers most modern USB and Bluetooth controllers. Vendor-specific extras like paddles or touchpads may not have a standard slot to appear in.

My controller works in the browser but not in my game. Why?

Games often use a different input API, their own bindings and their own dead zones. If every control responds in a browser test, the problem is almost always the game's configuration or a remapping tool running alongside it.