Nothing leaves your machine
The site is a set of pre-built static pages. When you press a button, the JavaScript on the page calls the browser's Gamepad API, reads the values for that frame, and paints them. Those values are not collected, batched or sent to a server, because there is no server-side component to send them to. There is no account to create and no controller identifier to store. Reload the page and the session starts from nothing.
The practical effect is that the tester works offline once the page has loaded, and that a diagnostic you run on a work machine leaves no record behind.
Why we never write to your controller
Some desktop utilities and a few browser tools go further than reading input: they open a raw device channel and write to the controller to adjust deadzones, remap buttons or store a calibration profile. We deliberately do not. Writing to arbitrary consumer hardware from a web page means sending vendor-specific commands to a device whose firmware revision you cannot verify, and the failure mode is a controller that needs a factory reset — or worse.
So the boundary is fixed: this site reads the standard Gamepad API, and the single outbound call it makes is the optional rumble request, which asks the browser to play an effect through a driver your operating system already loaded. No firmware access. No register writes. Nothing stored on the device. If a result here tells you the hardware needs correcting, the correcting belongs in the manufacturer's own tool.
What the reading can and cannot prove
Browser support varies by operating system, connection type, controller model and browser. The tool reports what the API exposes rather than pretending to be a hardware lab. A missing rumble button usually means your browser or connection does not support force feedback on that device, not that a motor is dead. An axis that reads 0.04 at rest is a real measurement of a real offset, but whether that offset matters depends on the game's own deadzone.
Where a value is an estimate, the interface says so. The polling rate test measures how often your browser hands over a fresh sample, which is an upper bound on what the site can observe — not the controller's own report rate.
Compare, then conclude
A single reading rarely proves anything. Test the same controller over a cable and over Bluetooth, in a second browser, and against a second controller if you have one. A fault that follows the device is a device fault; a fault that follows the browser or the cable is not.
Start with the button test for dead inputs, the joystick drift test for unwanted movement, and the controller not detected guide if nothing appears at all. The controller library lists the browser quirks that are already known for common models, so you can check whether the behaviour you are seeing is expected.