Type “controller polling rate test” into a search engine and you will find a dozen pages that will hand you a number in Hz. Run two of them on the same controller and you may well get two different answers. Run one of them on a 60 Hz laptop and then on a 144 Hz monitor, with the same pad, and you will get two very different answers.
The number is not random. It is your refresh rate.
The mechanism, in one paragraph
A browser does not receive gamepad input as events. There is no oncontrollermove. A page asks
navigator.getGamepads() for the current state, and the sensible place to ask is inside the
animation callback — the function the browser runs once per drawn frame. So a page can observe at
most one change of state per frame. At 60 fps that is sixty observations a second, at 144 fps a
hundred and forty-four, and it makes no difference whether the pad underneath is reporting at 125 Hz
or 1000 Hz.
Everything below follows from that one fact.
Why the number still tells you something
A ceiling reading is not worthless. It is a floor: your controller is keeping up with your display, which is the part that reaches the game. A frame that had no new controller data would be a frame your view did not turn, and that is exactly what you do not have.
What it cannot do is tell the difference between a pad that is comfortably ahead of your display and one that is only just keeping up. Both read the same.
When the number is real
If the reading sits clearly below your refresh rate, the controller is the slower of the two and the figure is a genuine measurement. This is common on Bluetooth, and it is the case worth acting on — some frames of your game will reuse the previous stick position because nothing newer arrived.
That is the whole decision tree:
- At the ceiling — nothing to fix here. A cable cannot raise a number the browser was never able to see past.
- Below the ceiling — the pad is the limit. Worth repeating over a cable, because the same pad wired usually reports far faster than it does over Bluetooth.
What the reference tables mean
Most polling-rate pages print a table like this one:
| Connection | Commonly reported |
|---|---|
| USB cable | around 1000 Hz |
| 2.4 GHz receiver | around 1000 Hz |
| Bluetooth, Xbox pads | around 125 Hz |
| Bluetooth, PlayStation pads | around 250 Hz and up |
Those figures come from the protocols, not from a browser, and they are useful context. But notice what the table means alongside the mechanism above: on a 144 Hz display, every single row except Bluetooth-Xbox is above your ceiling. A browser cannot distinguish any of them. The table is describing a range of hardware that a browser test collapses into one answer.
Why your stick has to be moving
A controller that is sitting still may stop sending packets at all — there is nothing to report, and the silence saves battery. A test that counted state changes while you kept your hands off would be measuring the idle rate and calling it the polling rate.
So every honest version of this test asks you to roll the sticks for the whole sample. If you see a suspiciously low number, that is the first thing to check before you conclude anything about the hardware.
What this means for a game
Almost nothing, and this is the part the Hz arguments usually skip. A game reads your controller on its own schedule — typically once per simulation tick or once per frame — for exactly the reason a browser does. A pad reporting at 1000 Hz into a game running at 120 fps is sending roughly eight packets per read, seven of which are superseded before anything looks at them.
The case for a faster pad is not that the game sees more of them. It is that the newest packet at the moment of the read is fresher: at 1000 Hz the data is at most a millisecond old, at 125 Hz it can be eight. That is a real difference and a small one, and it is a different claim from the one the Hz number appears to make.
How to get a number you can compare
- Measure on the machine you actually play on, with the display you actually use.
- Note your refresh rate beside the result. A controller reading without it is not interpretable.
- Roll both sticks for the whole sample.
- Repeat once. A single run that disagrees with two others is a scheduling hiccup, not hardware.
- If the number sits below your refresh rate, try a cable and measure again. If it sits at the ceiling, there is nothing here to improve.
The controller check runs this alongside drift, stick range, buttons and triggers, and prints the ceiling next to the reading. The input latency test reports the same measurement with the interval distribution behind it, which is more informative than either number alone.
The short version
A browser polls a gamepad once per drawn frame. Any controller polling rate a browser gives you is bounded by your refresh rate, so a reading at that ceiling means “at least this fast, and this page cannot see further”. Only a reading below the ceiling is your controller’s own number — and that is the only one worth trying to change.
