Getting started
What works where
Three tables say what works where: whether a controller shows on a computer, whether it shows on a phone or tablet, and which tests and tools work in each browser. Where a cell has more to it, it leads to the part that explains it.
Your system and browser, where this page can tell them, are marked Yours. The page reads them from your browser, on your device, and sends them nowhere.
Does it show on a computer?
| Browser | USB or dongle | Bluetooth | In full, through WebHID |
|---|---|---|---|
| Windows | |||
| Chrome, Edge and other Chromium browsers | Yes | Yes | Yes |
| Firefox | Yes | Yes | No |
| macOS | |||
| Chrome, Edge and other Chromium browsers | Most pads | Yes, some with + | Yes, not Xbox pads |
| Safari | Pads Apple supports | Pads Apple supports | No |
| Firefox | Most pads | Most pads | No |
| Linux | |||
| Chrome, Edge and other Chromium browsers | Yes | Yes | Once allowed |
| Firefox | Yes | Yes | No |
A browser on a computer shows a pad once a button on it has been pressed with the page open. Other browsers built on Chromium, such as Opera, Vivaldi and Brave, read pads through the Gamepad API as Chrome does; where one has no WebHID, PadBench leaves + out.
Firefox and Safari have no WebHID, so they read every pad through the Gamepad API alone, with no polling rate, chatter, motion, touchpad or battery. Safari sees only the pads Apple supports, such as Xbox, PlayStation and Switch Pro controllers; most arcade sticks and generic pads never show there.
Read more in Controller not detected
Does it show on a phone or tablet?
| System | USB or dongle | Bluetooth | In full, through WebHID |
|---|---|---|---|
| Android | Yes | Yes | No |
| iPhone and iPad | Some, by USB-C | Pads Apple supports | No |
No browser on a phone or tablet has WebHID, so there PadBench reads a pad through the Gamepad API alone: its buttons, sticks and triggers, with no polling rate, chatter, motion, touchpad or battery.
On Android, Chrome and the browsers built on it read pads paired over Bluetooth, or plugged into the phone's USB-C port, through an adapter where the pad's plug doesn't fit.
On an iPhone or iPad, every browser is built on Safari's engine, so each sees only the pads Apple supports, with at most 17 buttons, and the system keeps a pad's home button for itself. By cable, a device with USB-C reads some of those pads, Xbox pads from iOS 18 and iPadOS 18.
Which tests and tools work where?
| Test or tool | Chrome, Edge | Firefox | Safari | Android | iPhone and iPad |
|---|---|---|---|---|---|
| Vibrate: the vibration and motor tests | Most pads | No | Some pads | Some pads | No |
| Frequencies in the motor test | Some pads | No | No | No | No |
| An Xbox pad's trigger motors | Yes | No | No | No | No |
| A DualSense's trigger effects | With WebHID | No | No | No | No |
| Lights and the light test | With WebHID | No | No | No | No |
| Polling rate and chatter | With WebHID | No | No | No | No |
| Motion, touchpad and battery | With WebHID | No | No | No | No |
Vibrate shows among a pad's tools only where the pad can be rumbled, and the pad's Controller tab lists what PadBench can play or set on it. Firefox rumbles no pad, Safari rumbles pads only on a Mac, and Chrome on a phone only from Android 12, where the phone passes the rumble on. In Chrome on Windows, a DualSense rumbles only through WebHID, and an Xbox pad's trigger motors only by cable.
With WebHID means once the pad is read through WebHID, in Chrome or Edge on a computer, as its tools offer, or with + for a pad the browser doesn't list. The polling rate and chatter come from any pad that way; motion, touchpad, battery, lights and trigger effects from the pads PadBench knows, such as a DualSense, a DualShock 4 and a Switch Pro Controller.
The motor test's frequencies play on a Switch Pro Controller through WebHID, and on a DualSense by its cable, through its audio. The Windows app has every test and tool here, for the pads that have them, with nothing to allow.
A Bluetooth pad that doesn't show
Some pads, paired over Bluetooth, are listed in the system's Bluetooth settings and still never show on the page, most often on a Mac: the browser doesn't take them for a gamepad, so its Gamepad API leaves them out. In Chrome or Edge, + after the controller tabs opens the browser's list of devices. Choose the pad there, and PadBench reads it through WebHID, in full; the browser remembers it for this site.
Safari and Firefox have no WebHID, so there such a pad can't be read at all: open PadBench in Chrome or Edge for it.
Xbox and XInput pads on a Mac
Xbox pads by cable, and pads in their XInput mode, such as many fight sticks and boards running GP2040-CE, show on a Mac only from macOS 15 Sequoia, and not every XInput pad then. If one doesn't show, switch it to another of its modes, such as Switch or PS4, or pair an Xbox pad over Bluetooth instead. WebHID can't reach Xbox pads on a Mac, since macOS reads them itself.
Read more in Connecting a controller
WebHID on Linux
On Linux, every browser reads pads through the system's own drivers, by USB or Bluetooth, with nothing to set up. WebHID needs more: the browser can open a pad only if your account may use the pad's hidraw device, which most systems keep to the administrator. A udev rule gives that access, such as those Steam installs for the pads it supports, or one that tags the pad's hidraw device with uaccess. A browser installed as a Snap may not reach the pad even then.
The Windows app
The Windows app reads pads itself, by USB, Bluetooth or dongle, with nothing to allow: PlayStation, Switch and other HID pads report by report, in full, and Xbox pads through XInput. It keeps reading while a game has focus.