On this page
How the test works
There are two modes, and they measure genuinely different things. It's worth knowing which is which, because most "controller latency" tools online quietly conflate them.
1. Report rate & link health — a real measurement
This times the gap between successive reports coming out of your controller. No human is involved, so there's no reaction time to subtract: it's pure hardware and link quality. You get the actual reporting rate in Hz, the jitter (how much that interval wobbles), and a count of likely dropped reports.
If you grant access via WebHID, this is exact — WebHID is event-driven, delivering one event per real HID report. Without it we fall back to the Gamepad API, which the browser re-samples on its own schedule; that reading is capped by the browser's rate rather than your controller's, and the tool labels it as approximate rather than pretending otherwise.
Hold a button or move a stick. Many pads stop sending reports entirely when nothing changes — with an idle controller there is simply nothing to time.
2. Reaction comparison — a comparison, not a measurement
Press the button when the box turns green. Your absolute number here is mostly your own reaction time (150–250 ms is normal), not your controller's latency. We're explicit about this because it's the honest limit of any browser-based test: the page has no way to know when your finger physically moved, so it cannot separate you from the hardware.
What it is good for is a paired comparison. Run it wired, save the result, switch to wireless, run it again. Your reaction time is roughly a constant offset across both, so the difference carries real signal. The tool only flags a gap as meaningful once it exceeds the combined statistical noise of both runs — otherwise it says "within noise" instead of handing you a number that looks authoritative but isn't.
How to read your results
Report rates have moved a lot. 1000 Hz is the normal baseline for a modern controller, not a premium figure — and with overclocking (or natively, on a few pads) you can reach 8000 Hz.
| Report rate | What it usually means |
|---|---|
| 125 Hz | Older Bluetooth. Low by current standards. |
| 250–500 Hz | Older wired pad, or a conservative default. |
| 1000 Hz | The current baseline. Most modern controllers land here. |
| 2000–4000 Hz | High-rate territory — overclocked, or high-end native. |
| 8000 Hz | Top of the range. Overclocked, or one of the few pads doing it natively. |
- Jitter under 1 ms: a healthy, stable link. Above 5 ms: something is interfering.
- Any dropped reports on a cable: suspect the cable, the port, or a USB hub. On wireless, suspect distance or 2.4 GHz congestion.
- Reaction median 150–220 ms: normal, and dominated by you rather than the controller. Don't read it as hardware latency.
- A big reaction spread (±40 ms or more): usually you, not the pad — fatigue or distraction. Collect more trials before comparing setups.
Chasing a higher rate can make things worse
Above roughly 1000–2000 Hz, the limiting factor stops being the controller and becomes your PC — the USB controller, the driver, and how busy the CPU is. Pushing a pad to 8000 Hz on a host that can't sustain it produces dropped reports and jitter, and those are what actually make an overlay look choppy. Raw rate is not.
If the test reports a high rate together with dropped reports or high jitter, step the polling rate back down in your overclock tool — 8000 → 4000 → 2000 — and re-test until the drops disappear. The tool tells you this directly in its verdict when it sees that pattern.
One measurement caveat worth knowing: at very high rates the browser clock itself becomes the limit. performance.now() resolves to about 0.1 ms, while 8000 Hz means one report every 0.125 ms. At that point the tool switches to computing the rate over the whole run instead of per-interval, and reports jitter as n/a rather than printing rounding noise as if it were a measurement. The device-clock analysis below has no such limit — a DualSense timestamp resolves to about a third of a microsecond.
What this can't do (and what would be needed)
No browser tool can give you a true absolute controller latency figure, and it's worth being clear why: measuring it requires knowing when the button was physically pressed, and a web page has no access to that. It only knows when it observed the change.
That's why lab measurements use external hardware — a microcontroller that electrically shorts the button contacts and timestamps the moment, or a 1000 fps camera filming the pad and the screen together. They're buying a physical time reference that the browser fundamentally cannot have. Anything claiming a precise absolute hardware latency from a web page alone is measuring your reflexes and calling it hardware.
How to lower your latency
- Use a wired USB connection instead of Bluetooth/wireless when precision matters.
- Plug directly into the motherboard/console, not through a USB hub.
- Close background apps and browser tabs before testing or playing competitively.
- If you're troubleshooting an overlay specifically (not the raw controller), see our guide on fixing controller overlay lag — overlay delay is usually a Browser Source setting, not the controller itself.
Turn your controller into a live, transparent input overlay for OBS or Streamlabs in a couple of minutes.
Build your overlay →