Controller polling test. The report interval, not input lag.
A controller sends its state in reports, many times a second. This test measures the interval between them as the browser receives them, two ways: the Gamepad API, which every browser has and which is capped by how often the browser polls the pad (every 4 ms in Chrome and Edge), and WebHID, which in Chrome and Edge reads the controller's own reports. It prints a median, a spread, and which source it came from. It does not measure input lag, which no browser can.
One check · Five seconds a reading
Asks for: A controller, and a button press. It runs in its own window and nothing leaves this page.
In short
Controller polling test: the answer first
A controller polling test measures how often the controller's state reaches the browser. This one reads the Gamepad API in a tight loop and keeps every new timestamp, which every browser allows but which Chrome and Edge cap at their 4 ms polling, and in Chrome and Edge it can also count the controller's own reports over WebHID. Either way the figure is a report interval, not input lag.
Reading your result
- At 4 ms means the browser's cap
- A Gamepad API median at 4 ms in Chrome or Edge is the browser's polling, so the controller may be faster. The WebHID reading shows the controller's own rate.
- The spread matters as much as the median
- The 10th to 90th percentile shows how evenly the reports arrive. A wide spread over Bluetooth usually means interference or distance.
- Which source
- The result names the Gamepad API or WebHID. Compare like with like: the same source, the same link, the same browser.
What it measures
Measured here, not assumed.
- Gamepad API update interval
- The page reads the controller in a tight loop on the main thread, far more often than once a frame, and keeps every change of Gamepad.timestamp while you roll a stick for five seconds. The median interval and the 10th to 90th percentile are the figure. Pauses over 100 ms (our line) are the stick at rest and are left out.
- The browser's cap, named
- Chromium polls gamepads every 4 ms, about 250 Hz (kPollingIntervalMilliseconds in its gamepad_provider.cc). A median at 4 ms is reported as the browser's cap, not the controller's: the pad may be faster.
- WebHID report interval
- In Chrome and Edge, pick the controller in the browser's list and the page counts its input reports for five seconds: the device's own interval, past the gamepad polling. It also lists the report numbers and sizes it saw, which tell a Sony pad's USB, Bluetooth simple and Bluetooth full reports apart. Nothing is sent to the controller.
- Which controller
- The vendor and product numbers the browser reports, matched against Chromium's own list of controllers, with a link to the page for that model.
- Drift at rest
- While the window is open, each stick is read the gamepad tester's way: still for a second and outside our 8 percent dead zone is drift.
If it fails
The usual failures, and what fixes each.
- The intervals are uneven over Bluetooth
- Radio interference and distance spread the intervals. Move closer, take the receiver off the back of the computer with a USB extension, or use a cable and measure again.
- The controller is not seen
- Press a button after connecting: browsers list a controller only after a press. On Bluetooth, forget and re-pair it.
- The controller is missing from the WebHID list
- The list is filtered to Sony, Microsoft, Nintendo and 8BitDo. A wired Xbox pad never appears there; use Bluetooth, or read the Gamepad API figure. Close Steam or a remapper that holds the pad, and try again.
Where a browser stops
What it cannot tell you.
- Input lag. The time from a press to the screen changing needs a camera or a photodiode; a browser sees only when the data arrived.
- The controller's rate through the Gamepad API when it is faster than the browser's polling. WebHID gets past that, for controllers that speak HID.
- Xbox controllers on a cable, and the Xbox Wireless Adapter. They do not use HID over USB, so WebHID cannot list them.
- WebHID outside Chrome and Edge on a computer. Firefox and Safari do not offer it; the Gamepad API reading still works there.
- Buttons, triggers and circularity. The gamepad tester checks those.
Privacy
Nothing leaves this page.
The camera and microphone are read on this page and stopped as soon as they have been measured. The clip you can play back lives in the browser's memory and is discarded when you leave. The location check discards the position. The internet test sends random bytes to this site and nothing else. The result is stored nowhere unless you ask for it by email, and then only the fact that an email was sent is kept.
Questions
Controller polling test, answered
- How do I check my controller's polling rate?
- Open the test, press a button, start a measurement and roll a stick in circles for five seconds. The result is the median interval between updates in milliseconds and the rate in Hz. In Chrome or Edge, the WebHID reading measures the controller's own reports.
- Is polling rate the same as input lag?
- No. Polling rate is how often the controller sends its state; input lag is the whole delay from a press to the picture changing, which also includes the game and the screen. A faster report rate trims a little from it, on average half the interval.
- Why does my controller read 250 Hz in Chrome?
- Chrome and Edge poll gamepads every 4 ms, which is 250 Hz, so the Gamepad API cannot show more. The WebHID reading, where your controller offers it, shows the controller's own rate.
- Does this work in Firefox or Safari?
- The Gamepad API reading does. WebHID is only in Chrome and Edge on a computer, so the second reading is not offered elsewhere.
- Does a higher controller polling rate reduce input lag?
- A little: on average a press waits half a report interval for the next report, so going from 250 Hz to 1000 Hz saves 1.5 ms on average. The game and the screen add more, and no browser can measure those.
Read next