Test the motion sensors your browser can actually access, your device's own gyroscope and accelerometer on phones and tablets, plus any gamepad level pose data a connected controller exposes, with an honest answer about what most controllers cannot share with a browser at all.
This is the single most important thing to understand before using this tool. The internal gyroscope and accelerometer built into controllers like the DualSense or a Joy Con are almost never exposed to a web browser. The W3C Gamepad API, the standard every tool on this site is built on, defines an optional pose property for exactly this kind of motion data, but in practice essentially no current browser implementation surfaces it for these controllers, which means a page like this one genuinely cannot read your controller's built in motion sensor, regardless of how the tool is built.
What a browser can access reliably is the motion sensor hardware inside the device you are using to browse the web itself, the gyroscope and accelerometer built into a phone or tablet, through a separate and well supported set of browser APIs designed for exactly that. So this tool runs two genuinely different checks. One tests your phone or tablet's own built in motion sensors directly. The other checks whether your currently connected gamepad happens to be one of the rare exceptions that does expose pose data through the API, and tells you plainly if it does not, rather than pretending to show you data that was never actually available.
Live tilt position, tip your device in any direction to move the dot.
Checking for a connected controller…
Beta is your device's tilt forward and backward, ranging roughly from negative 180 to positive 180 degrees, with zero meaning the device is lying flat. Gamma is tilt left and right, ranging roughly from negative 90 to positive 90 degrees. Alpha is compass style rotation around the vertical axis, from 0 to 360 degrees, though alpha specifically is only meaningful on a device with a working magnetometer and properly calibrated compass, and reads as unreliable noise on plenty of devices and browsers even when beta and gamma work perfectly.
This is the combined strength of acceleration across all three axes, including the constant pull of gravity itself. A device sitting completely still and flat should read close to standard gravity, roughly 9.8 metres per second squared. Picking it up, shaking it, or moving it quickly will push this number noticeably higher for as long as the motion continues.
This translates beta and gamma into a single visual position, the same way a spirit level or a simple balancing game would represent tilt. It is the fastest way to sanity check that the raw numbers above are behaving the way you would expect just by physically tipping the device around in your hand.
This section checks your connected gamepad object directly for a pose property containing real orientation or motion data. The honest, and far more common, result here is that this comes back empty even on controllers with genuine internal motion sensors, like a DualSense, because that data is simply not exposed through the browser's Gamepad API on essentially any current browser. A result showing actual pose data here would be a genuine rarity worth taking note of.
This is not an oversight or a missing feature waiting to be added, it reflects a real and longstanding gap between what the Gamepad API specification allows for and what any browser vendor has actually chosen to implement for these particular controllers. Exposing raw motion sensor data from a controller carries its own set of security and fingerprinting considerations browser vendors weigh carefully, and for gamepads specifically, the practical demand for this in web content has historically been limited enough that no major browser has prioritised building it out, even though the specification leaves room for it.
Native applications and games, which integrate with a platform's own controller libraries directly rather than going through a browser, do not have this limitation, which is why a PS5 game can absolutely use DualSense gyro input for aiming or menu navigation while a browser based page fundamentally cannot replicate that, no matter how the page itself is built.
Some browsers, particularly desktop Chrome and Firefox on a laptop without physical motion hardware, simply do not expose motion events at all since there is no sensor present to report from. This tool is only meaningful on a phone or tablet that actually contains the hardware in question.
iOS requires the permission request to be triggered directly by a tap on the Allow motion access button itself, rather than happening automatically on page load, which is a deliberate privacy requirement rather than a fault. If you dismissed the prompt or denied it once, you may need to reset that permission in Settings, under Safari, before this page can ask again.
This is common and usually not a fault in your specific device. Compass based heading is sensitive to nearby magnetic interference and often needs a manual figure eight calibration motion that varies by device and operating system, so treat alpha as the least reliable of the three readings here.
This is the expected, normal result for the overwhelming majority of controllers in the overwhelming majority of browsers, covered in detail in the scope section above, and is not something specific to your hardware or a sign anything is wrong with your setup.
If your device's motion readings look unusual, a permission prompt will not appear when you expect it to, or you want a second opinion on what a result actually means, reach out directly. A short description of what you are seeing, along with your device model and browser, is normally enough to help track down what is going on.
info.gpadviewer@gmail.comSign in to your account