Gamepad Support in Browser Games: The Gamepad API Explained
Plug in a controller, and a surprising number of browser games will recognize it instantly. The catch is you usually have to press a button first — and that quirk tells you a lot about how the whole system works.
If you've ever plugged a controller into your laptop, opened a browser game, and had nothing happen until you mashed a button, that's not a bug in the site. It's a deliberate quirk of the Gamepad API, the browser feature that lets web pages read input from connected controllers.
Why Nothing Happens Until You Press Something
Browsers don't broadcast connected devices to every page that loads, for the same privacy reasons they don't hand over your webcam feed without asking. A page can call navigator.getGamepads(), but on most browsers that call only returns useful data after the user has interacted with the controller in a way the browser can detect — typically pressing any button or moving a stick past its dead zone. This is a deliberate fingerprinting mitigation: without it, a site could silently enumerate every controller you've ever plugged in and use the combination as a tracking signature. Requiring an interaction first means the page only learns about a controller when you've clearly chosen to use it with that page. The full behavior is specified in the W3C Gamepad specification, including exactly which events fire and what data each gamepad object exposes.
What the API Actually Exposes
Once connected, a game reads a snapshot of the controller's state on every frame: an array of button objects, each with a pressed boolean and an analog value between 0 and 1 (useful for trigger pressure, not just a binary click), and an array of axis values for sticks, each ranging from -1 to 1. There's no event that fires "button pressed" the way a keyboard fires a keydown event; instead, the game polls the gamepad's state every frame inside its main loop and compares it to the previous frame to detect changes. This polling model fits naturally with how browser games already structure their render loop around requestAnimationFrame, so adding gamepad support to an existing game usually means adding one more state check per frame rather than restructuring anything.
The Mapping Problem
Controllers are not standardized in their physical layout, and the API has to account for that. Most modern controllers report through a "standard" mapping, which guarantees button zero is always the bottom face button, button one is always the right face button, and so on, regardless of whether the physical pad is a wireless console controller or a generic USB pad. Older or less common controllers sometimes report as mapping "" (empty string), meaning the browser couldn't confidently map their buttons to the standard layout, and the game has to either guess based on button count or ask the player to configure their own bindings. This is the single biggest source of "my controller doesn't work right" bug reports for browser games that support external input, and it's why well-built games include a manual rebind screen rather than assuming the standard layout holds for every device.
Multiple Controllers, Local Multiplayer
Because getGamepads() returns an array, not a single object, a browser page can read input from several controllers at once with no extra plumbing beyond tracking which index belongs to which player. That's the entire technical foundation behind browser games that support same-device multiplayer — two people, two controllers, one tab. The API doesn't distinguish between "the primary controller" and "a second one" in any special way; it's just a list, indexed in the order the browser detected each device.
What It Still Can't Do
The Gamepad API has real limits. It doesn't expose rumble or haptic feedback consistently across browsers, and where haptics are available, the API is newer and less universally supported than the core button-reading functionality, so relying on it for a core mechanic is risky. It also can't read a controller's battery level or, on some browsers, its exact hardware identity beyond a vendor and product ID string, which limits how precisely a game can tailor its button-icon prompts (showing the right console-specific glyph for the button you're pressing) without some guesswork based on that ID string.
Why Bother, Given the Friction
Despite the quirks, gamepad support has become close to standard for browser games in genres where keyboard-and-mouse feels wrong — racing games, fighting games, and platformers especially. A racing game controlled with analog trigger pressure for acceleration feels meaningfully better than one bound to a binary keyboard key, and that difference is often enough to justify the extra testing burden of supporting multiple controller mapping quirks. For a genre built entirely around removing friction between "finding a game" and "playing it," gamepad support is one of the few areas where browser games willingly accept a bit of setup friction because the payoff in feel is worth it.