How JoyCheck reads your controller

JoyCheck is a browser-based controller tester that reads your gamepad through the W3C Gamepad API, with no install and nothing sent to a server.

6 input types · 4 sections · 10 min read

JoyCheck reads your controller using the W3C Gamepad API[1], a browser-native interface that exposes every button, analog axis, and trigger as numeric values updated 60 times per second. The browser handles the USB or Bluetooth handshake; JoyCheck polls navigator.getGamepads() on each animation frame and renders the live state without sending data to any server.

Updated on 2026-05-27 by Taimoor Bamazai, founder of Elites Algorithm Limited (a registered tech company in Dublin, Ireland) and the engineer behind JoyCheck.

The live data flow has three properties worth naming:

• Browser-native. Standard W3C Gamepad API. No native binary, no driver install. Works in every modern Chromium browser, Firefox, and Safari 16+.
• 60 to 144 Hz polling. JoyCheck reads navigator.getGamepads() on each animation frame, the same rate the browser repaints, matching your display Hz.
• Zero data sent. Every input is processed in your browser process. No XHR, no fetch, no analytics on the widget. Verifiable in DevTools.

What does it mean to “read” a game controller?

JoyCheck reads six classes of input from your controller, and each maps to a specific field of the Gamepad API.

• Buttons (gamepad.buttons[]). Each button is a GamepadButton object that reports its pressed state and, where supported, an analog value.
• Analog sticks (gamepad.axes[0..3]). The axes array is a flat float array. Under the W3C standard mapping it holds the left and right stick X/Y positions.
• Triggers (gamepad.buttons[6,7].value). Triggers live in the buttons array and are treated as buttons with an analog value under the standard mapping.
• Touchpad (gamepad.touchEvents[]). DualShock 4 and DualSense expose touchpad coordinates as an extension to the Gamepad API. The touchpad’s reported resolution is roughly 1920×1080, and up to two simultaneous touch points are tracked.
• Gyro and IMU (gamepad.imu, proposed). DualSense, Joy-Con, and Switch Pro all expose six-axis IMU data.
• Vibration (gamepad.vibrationActuator.playEffect()). The vibrationActuator interface on a Gamepad object exposes a playEffect() method that takes a duration and intensity for each motor, on the standard controllers that report haptic actuators.

How does the W3C Gamepad API actually work?

The Gamepad API is a W3C-standard browser interface that exposes connected game controllers to JavaScript. It ships in every modern browser since Chrome 21 (2012), Firefox 29 (2014), Edge 12 (2015), and Safari 14.1 (2021), see Can I Use for the current support matrix.[2]

The browser handles the underlying USB or Bluetooth HID handshake. Your operating system pairs the controller; the browser sees it via OS-level driver layers (XInput on Windows, IOHIDDevice on macOS, evdev on Linux); the page calls navigator.getGamepads() and receives a snapshot array of Gamepad objects.

Each Gamepad object exposes a set of fields:

• id: a string identifier (e.g. “DualSense Wireless Controller (STANDARD GAMEPAD Vendor: 054c Product: 0ce6)”)
• axes[]: a float array of analog axis positions (sticks, typically four entries: left X/Y + right X/Y)
• buttons[]: an array of GamepadButton objects, each with pressed, value, and touched properties
• timestamp: last update time in milliseconds
• mapping: “standard” if the controller maps to the W3C standard gamepad layout; "" otherwise
• vibrationActuator: a haptic feedback interface (where supported)

The API requires a user gesture (button press) before it exposes connected controllers. This is the gesture requirement: a privacy feature that prevents pages from fingerprinting your controller in the background. JoyCheck displays “Press any button to begin” until the gesture fires.

Why JoyCheck polls instead of subscribing to events

The Gamepad API is poll-only in the standard. There’s no onbuttonpress event you can subscribe to, your code asks navigator.getGamepads() and gets a snapshot of the current state. JoyCheck polls using requestAnimationFrame[5], which fires the callback at the browser’s display refresh rate (typically 60Hz, up to 240Hz on high-refresh-rate displays).

Polling at the refresh rate is the right cadence because:

• The OS updates the controller state at roughly that rate (USB HID polls at 1kHz; the browser samples down)
• Rendering happens at the refresh rate, so any extra polls would produce duplicate frames with no visual difference
• It keeps CPU usage minimal, the polling callback is one function call per frame

Polling faster (via setInterval or setTimeout) wastes CPU and produces duplicate snapshots. Polling slower (e.g., 30Hz) misses fast button presses on high-refresh displays. requestAnimationFrame matches the display, which matches what you actually see.

Why is JoyCheck zero-data and how can I verify it?

We say this three times because it matters:

1. JoyCheck does not transmit any controller data to any server, ever.

2. The Gamepad API runs entirely inside your browser process. Controller state never leaves the page.

3. View source on the widget: every API call resolves to a requestAnimationFrame callback that updates DOM nodes only. There are no fetch() calls, no XMLHttpRequest, no WebSocket touches that carry controller data.

You can verify this yourself in under a minute: open JoyCheck in any browser, open DevTools (F12), click the Network tab, clear the log, and exercise the widget for 30 seconds. The Network tab stays empty for controller-state requests. Full statement on the privacy page.

Why use a browser tester instead of a desktop app?

Three reasons:

No install friction. The Gamepad API is now reliable enough that asking users to download and run a binary is an unnecessary tax. A page load is faster than an installer; a browser is more universal than Windows-only .exe distribution.

Cross-platform free. The same page works on Windows, macOS, Linux, and ChromeOS without per-platform builds. A browser tester ships once.

Auditable in 30 seconds. A web page’s network activity and storage are inspectable with browser DevTools by any user, any time. A desktop app’s network activity requires tcpdump, Wireshark, or lsof and root permissions. The audit story matters.

“Across years of hardware-diagnostic work on PC peripherals and game controllers, browser-based testers have caught roughly two-thirds of the faults that a desktop diagnostic utility would never have surfaced. The browser reads what the controller is physically reporting, which is a different layer of truth than what any installer-based driver exposes.”

Taimoor Bamazai, founder, Elites Algorithm Limited

What are JoyCheck’s known limitations?

Honest list, what JoyCheck does not do:

• No raw HID access. Reading the raw USB HID descriptor would require WebHID, a separate W3C spec with less consistent browser support (Chrome and Edge only, today).

• Pre-Gamepad-API controllers. DirectInput-only controllers from before XInput existed don’t appear in the browser. They’d need WebHID + a translation layer.

• Rumble support varies by browser. Firefox lags Chrome on vibrationActuator; Safari has limited support. JoyCheck reports the limitation gracefully.

• Trigger pressure on Xbox controllers depends on the driver layer. Some Bluetooth pairings report binary triggers (just on/off, no analog range). A wired USB connection usually fixes this.

For platform-specific diagnostic paths beyond what the browser can see, the dedicated walkthrough covers fault patterns that need hardware-side intervention.

For controller-specific diagnostic walkthroughs that use this same browser-based reading layer, the Switch Pro Controller pairing guide, the DualSense calibration walkthrough, and the PS4 controller calibration guide cover platform-specific pairing quirks the Gamepad API alone cannot resolve.

JoyCheck polling rate observations (measured 2026-05)

Browsers cap Gamepad-API readout to requestAnimationFrame cadence. In our analysis we measured the same controllers under identical display conditions. All readings: fresh Chrome 120 session, USB connection unless noted, sliding 5-second window.

Measured by the JoyCheck in-browser sampler. 144 Hz displays raise the cap proportionally; readings normalised to a 60 Hz baseline for cross-browser comparison.