Sensor Types

I assumed sensors were native-app territory.

Install an app, grant permission, get accelerometer data. That was the mental model -- a privileged channel only native code could touch. A web page reading the same chip? Not in the picture.

The accelerometer has been accessible from a browser since 2009. The chip was never native-app exclusive. Nobody put it in the tutorial.

What a Sensor Actually Is

A sensor is a chipset soldered into your device that measures a physical property and reports it as a continuous stream of numbers. There's no special unlock required to read it -- the chip runs whether or not any code is watching.

That detail matters for battery life. Most phone sensors run continuously regardless of your app. The OS needs them to handle screen rotation, step counting, and orientation lock. Your JavaScript doesn't power the sensor on. It just subscribes to a data stream that's already flowing. These sensors fall into the light-green API tier -- Chrome and Android have the deepest coverage, Safari has a subset.

Accelerometer

The accelerometer measures force on three axes: X, Y, and Z. Each axis reports a value in meters per second squared.

Hold your phone still and read the accelerometer. You won't see zero. You'll see roughly 9.8 on one axis -- Earth's gravitational pull. Flip the phone upside down and the same axis reads -9.8. Tilt it sideways and the gravity value shifts across axes.

That's how the OS knows to rotate the screen. That's also how a gravity game lets you steer a ball by tilting the phone. The same data stream, different uses.

Gyroscope

The gyroscope measures rotational velocity, not linear force. Where the accelerometer asks "how hard is something pushing?", the gyroscope asks "how fast is the device spinning?"

Readings come as alpha (rotation around the Z axis), beta (around X), and gamma (around Y). Slowly rotating the phone in your hand shows up as a changing alpha value. Pitching it forward and back changes beta.

The gyroscope is what powers 360-degree photo viewers and virtual reality on the web. Point the phone at a scene and rotate -- the gyroscope tracks the angle, the JavaScript updates what you see.

Magnetometer

The magnetometer measures the ambient magnetic field. It's the compass chip -- it tells you which direction is north relative to the device.

A compass app uses the magnetometer. So does any navigation experience that needs a bearing. The values are raw magnetic field strength on three axes, which the browser maps to a compass heading.

Proximity Sensor

The proximity sensor detects whether something is physically close to the phone's screen. When you hold a phone to your ear during a call, the screen goes dark -- that's the proximity sensor telling the OS to shut off the display to prevent accidental taps.

A web app can read this too. Useful for phone-call UI experiences or games where pressing the phone against a surface should trigger an action.

Ambient Light Sensor

The ambient light sensor measures illuminance in lux -- how bright the room around the device is.

This sensor has a complicated browser history. It was available in Chrome for a while, then removed. The reason: someone realized that the brightness of your screen affects the ambient light readings, which means a tab could potentially infer what's showing on neighboring tabs by watching how the light values change. The privacy implications were significant enough that the browser vendors pulled it from stable releases. It still exists behind an experimental flag.

We'll cover this more in the next post, since it connects directly to why sensor security isn't always obvious.

Altimeter and Humidity

Some devices go further than the standard set. iPhones include a barometric pressure sensor that functions as an altimeter -- this is how fitness apps detect stair climbing and floor changes. Samsung Galaxy devices have shipped with humidity sensors that measure moisture in the surrounding air.

These are not yet exposed through any stable web API. They exist in the hardware. The web platform will likely surface them eventually.

Why Any of This Matters for a Web App

The practical use cases are simpler than the hardware sounds.

Orientation-aware CSS effects. A title that shifts perspective as the user tilts the phone. A background that parallax-scrolls based on device angle. A header that catches the light differently depending on rotation.

Gravity games. Tilt the phone to steer. Shake it to trigger something. No gamepad or touch event required.

Usage-aware UI. A phone tilted almost flat is probably sitting on a table. A phone held upright at reading distance is in someone's hand. Detecting this lets you adapt the experience to context.

None of these require a permission dialog on Android. The sensor chips are already running. You subscribe, you read, you use the data.

Two different JavaScript APIs give you access to these sensors -- one from 2009 that works everywhere, and one from 2017 that works only on Chrome. Understanding which API to use and when is the next piece.

The Essentials

1. Phone sensors are always running. Your JS subscribes to an existing data stream -- it does not start a new one and costs no extra battery.
2. The accelerometer reports force on X/Y/Z. A stationary phone shows ~9.8 m/s² (gravity) on one axis.
3. The gyroscope reports rotational velocity as alpha, beta, gamma. The magnetometer reads magnetic field direction.
4. Ambient light was removed from stable browsers over privacy concerns. The sensor exists in hardware but is behind an experimental flag.
5. Proximity, altimeter, and humidity sensors exist in devices but have limited or no stable web API exposure.

Further Reading and Watching

• Use Device Motion for Fun Interactions -- Web Native (YouTube) -- practical walkthrough of building tilt and motion effects with DeviceMotionEvent
• Generic Sensor API -- web.dev -- Google's guide covering the full Generic Sensor API with live demos and code examples