Pick An API
Device Orientation reports tilt and heading as events. Geolocation reports a position with an accuracy radius. Each sits behind a permission gate.
Drive a simulated phone: move orientation angles to see DeviceOrientationEvent fields, and request a location to read its accuracy radius, permission flow, and watchPosition updates.
Move the orientation angles and watch the exact fields a
deviceorientation event would deliver, plus the gravity vector the
same pose would put on the accelerometer. Then switch to Geolocation to request a
fix, read its metres accuracy radius, walk the permission prompt, and simulate
watchPosition updates. Every number here follows from a stated model,
not a real sensor.
Device Orientation reports tilt and heading as events. Geolocation reports a position with an accuracy radius. Each sits behind a permission gate.
Requesting a sensor shows the browser's permission prompt. Choose Allow or Block and see how the reading, or the error, changes.
Watch alpha, beta, gamma, latitude, longitude, and accuracy update live, next to the exact JavaScript handler that would produce them.
A live value is not a result. Check whether the accuracy radius is smaller than your question and whether the pose matches your placement claim.
This page wants to use your device sensors while you use it.
Set the three Euler angles. Try a preset first, then fine-tune with the sliders.
Choose a positioning source, request a fix, then decide if its accuracy is good enough for your task.
A held-still device reports three angles. The gravity vector below is what a paired devicemotion event would show for the same pose.
Heading from alpha: 0° (N). Rotating the phone flat on a table changes only this heading, not the gravity reading.
event.alpha heading0.0°event.beta front-back0.0°event.gamma left-right0.0°accel.x0.00accel.y0.00accel.z9.81gx = -cosβ·sinγ·g,
gy = sinβ·g,
gz = cosβ·cosγ·g with g = 9.81. Independent of
alpha. Illustrative; a real sensor adds noise and motion.
A fix is a point plus a radius. Compare the radius with the distance your task must resolve before you trust it.
latitude--longitude--accuracy (m)--timestamp--alpha: heading about z, 0..360°.beta: front-back tilt about x, -180..180°.gamma: left-right tilt about y, -90..90°.coords.latitude, coords.longitude.coords.accuracy: a radius in metres, at 95% confidence.timestamp: when the fix was produced.enableHighAccuracy, timeout, maximumAge.requestPermission() from a gesture.Set "Flat on table". Note that gravity sits almost entirely on accel.z and tilt from flat is near 0°. Now choose "Face down": which field flips sign, and why does that support a placement claim?
Keep beta and gamma at 0 and sweep alpha across the full range. The compass turns, but the gravity vector does not move. Explain why heading cannot be recovered from gravity alone.
Switch to Geolocation, choose Wi-Fi indoors, set the task distance to 10 m, and request a fix. Is the ratio above 1? Record the reject-or-defer decision rather than forcing the reading.
Request access and press Block. The reading never arrives and an error state is recorded. Explain why a denied outcome with a timestamp is still valid lab evidence.
The field names, ranges, axis meanings, and the accuracy-as-metres-radius definition follow the W3C DeviceOrientation Event and Geolocation specifications. The permission-first flow mirrors real browser behaviour.
The gravity vector uses gx=-cosβ·sinγ·g, gy=sinβ·g, gz=cosβ·cosγ·g, verified against a full Z-X'-Y'' rotation matrix. Accuracy ranges and coordinates are illustrative, not measured.
A displayed value is not a result. Read the axis convention, the placement, the accuracy radius, the timestamp, and the permission outcome before you accept any mobile web reading.