DeviceBenchFree browser gamepad tester
Gamepad tester for every button, axis and trigger
Press any button on the pad and this page starts printing what your controller is actually sending: the id string it identifies itself by, how many buttons and axes it claims, the analog value under every button, and the position of every stick to three decimals. Nothing is drawn as a picture, so a device the browser could not remap — the kind that reports button 4 where a bumper should be — reads correctly here instead of being forced into a shape it does not have. Battery level, firmware version and serial number are not on the wire at all, so no page can show you those.
- 100% free
- No signup
- Any brand
- Live analog values
- Rumble test
How to test a controller in the browser
Three passes: wake the device, walk the controls, keep the evidence.
Connect the pad, then press one of its buttons
Plug in the cable, or pair over Bluetooth and wait for the light to settle. Nothing appears yet, and that is not a fault: a browser withholds every controller from a page until an input arrives, so the panel stays empty for a pad that is merely connected. Click once anywhere on this page to give it focus, then press A, Cross, or squeeze a trigger. The readout fills in on that press.
Work through the controls one at a time
Press each button on its own and watch which cell turns amber and what number appears under it. Triggers are the interesting ones because they sweep from 0.000 to 1.000 rather than snapping, so pull each one slowly and check the bar climbs smoothly instead of jumping straight to the top. Then roll both sticks around their rims and confirm each axis reaches 1.000 and -1.000 in turn.
Copy the readout before you close the tab
Copy result puts the device id, the button and axis counts, whatever is held at that moment and every axis away from center onto the clipboard as plain text. That is the format a seller, a repair shop or a forum thread can actually read, and the id string is what tells them which revision of the controller you have rather than which box it came in.
Technical specifications
| Controllers at once | 4 — the browser's slot list is fixed at four and every occupied slot gets its own tab here |
|---|---|
| Buttons shown | All of them: 17 on a standard-mapping pad, and however many an unmapped device chooses to report |
| Button precision | 0.000-1.000 per button; triggers use the whole range and every other button reports only 0.000 or 1.000 |
| Axis range | -1.000 to 1.000, three decimals; up on a stick is a negative Y because the axes follow screen coordinates |
| Sampling | Once per screen redraw — 60 readings a second on a 60 Hz display, 144 on a 144 Hz one, and none at all in a background tab |
| Rumble | dual-rumble via vibrationActuator, 400 ms at full strong and half weak magnitude; Chromium-family browsers only |
| Unmapped devices | Supported — mapping: "" is labeled as such and buttons fall back to their raw indices rather than borrowed names |
| Device id handling | Printed on screen and included in the clipboard summary only; never uploaded, never stored, gone on reload |
Frequently asked questions
The controller is plugged in but the page says nothing is connected. Why?
Because a connected pad is deliberately invisible until you use it. Browsers hold controllers back from the page until the first button press or trigger pull, so that a site cannot quietly enumerate your hardware while you read an article — the same reasoning behind hiding the exact list of fonts you have installed. Press any button and the device appears immediately. If it still does not, click on the page first: a tab that has never been interacted with can be skipped over entirely.
My pad shows Button 12 where the D-pad should be. Is it broken?
No, it is unmapped, and the page is telling you so in the mapping row. The Gamepad API has two modes: a device the browser recognized is remapped onto the standard layout and reports mapping: "standard", and everything else reports an empty string and hands over its indices exactly as the firmware numbered them. Third-party pads, adapters and older sticks land in the second group, where index 4 is not a bumper and axis 2 is not a right stick. Everything still works; you just have to learn your own device's numbering by pressing one control at a time.
Can I test two controllers at once?
Yes — the browser keeps four slots and this page lists every one that is occupied, with a row of buttons to switch between them. Each pad has to be woken with its own button press before it takes a slot. Slot numbers are assigned in the order the pads announced themselves and are not tied to the physical port, so unplugging the first pad does not renumber the second.
The rumble button does nothing.
Rumble reaches the page through vibrationActuator, and that is Chromium-only: Chrome, Edge, Opera and Arc have it, Firefox and Safari do not expose it at all. Even in Chromium it depends on the connection — a pad over USB almost always buzzes, while the same pad over Bluetooth on macOS frequently reports an actuator that quietly does nothing. The page distinguishes the three cases: no actuator, an effect the browser refused, and an effect the browser accepted. If it says accepted and you felt nothing, the request left the browser and the motors or the wireless link are where it stopped.
My triggers jump straight from 0 to 1 instead of sweeping.
That is the signature of a pad being read through the wrong driver rather than a broken trigger. Xbox-style controllers running as DirectInput devices, and a good number of generic USB pads, expose the triggers as ordinary digital buttons or fold both of them onto one shared axis, so the analog travel never reaches the browser. Reconnecting over USB, or letting the operating system install its own driver instead of a vendor one, usually restores it. If one trigger sweeps and the other snaps, that is hardware.
Can I check a pad that is paired to a tablet rather than a computer?
Yes — mobile browsers expose the same interface, so a controller paired over Bluetooth reads exactly as it would on a desktop. Chrome on Android handles Xbox, DualSense and most generic Bluetooth pads; Safari on iPadOS and iOS has had the interface since iOS 10.3 and gained DualShock and Xbox support in 14.5. The one thing to expect is a different id string for the same controller on each platform, because the text comes from whichever driver claimed it. A tablet with nothing paired will sit on the waiting panel indefinitely, which is the right answer rather than a stall.
Does the page learn which controller I own?
The id string is read, printed on screen and used to choose which button names to show, and it goes no further than the tab. It is not sent anywhere and it is not stored; it appears in the clipboard text only when you press Copy result, and reloading the page throws all of it away.
About reading a controller from a web page
The Gamepad API is unusual among browser interfaces in having no events worth listening to. gamepadconnected fires once and then goes quiet forever; button and axis values only change when a page calls navigator.getGamepads() and reads the fresh snapshot it returns. There is no way to subscribe to a stick moving. Every controller readout on the web, this one included, is therefore a polling loop tied to the screen’s redraw, which is also why a background tab shows a frozen pad rather than a wrong one — the browser stops updating the snapshots there, and a page that kept drawing would be drawing history.
The second thing worth knowing is that the standard mapping is a courtesy, not a guarantee. When the browser recognizes a device it rearranges its controls onto a fixed 17-button, 4-axis layout borrowed from the Xbox pad, and reports mapping: "standard" to say so. Everything it does not recognize reports an empty string and arrives in raw firmware order. Plenty of tools skip that distinction and draw an Xbox pad regardless, which is how an owner of a cheap USB controller ends up convinced their A button is broken when the firmware simply put it at index 2. If your pad does report the standard layout and you would rather see it drawn with names on it, the Xbox controller tester does exactly that; if it has more axes than a pad has business having, the joystick test gives each of them its own bar.
Most faults show themselves in under a minute here. A button that never turns amber is a switch that has stopped closing. A trigger whose bar starts above zero when your finger is nowhere near it has a worn return spring or a shifted sensor. An axis that will not reach 1.000 in one direction has either a physical obstruction or a stretched gate. And a stick that will not sit still while the pad is face-down on the desk is the fault everyone means when they say a controller is worn out — the stick drift test puts a number on that one over a full minute, which is what a warranty claim wants. Timing is the one thing this page cannot give you: polling is bounded by the display, so the delay between your thumb and the screen is a question for the keyboard latency test, which measures the same browser-side ceiling on a device that can be pressed precisely. And if you are checking over a whole second-hand bundle rather than one pad, black screen and white screen are the two fields that find a stuck pixel on the display that came with it.
What the page does with your controller's id
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The id string a controller reports — vendor code, product code and a product name — is read to pick button labels and printed so you can see it. It is never transmitted, and the only time it leaves this tab is when you press Copy result and paste it somewhere yourself.