Generic Sensor API

Generic Sensor API — per MDN, the Sensor APIs are “a set of interfaces built to a common design that expose device sensors in a consistent way to the web platform.” Developers use concrete subclasses such as Accelerometer, Gyroscope, Magnetometer, and AmbientLightSensor rather than the base Sensor interface directly.

Browser & ecosystem support

Support differs per sensor interface, so the table below covers Accelerometer as the representative implementation:

• Legend
• Yes
• Partial
• Flag
• No
• Unknown

Browser / Platform	Support	Versions	Confidence	Source	Notes
Chrome (Desktop)	Yes	67	high	source	—
Chrome (Android)	Yes	67	high	source	1
Edge (Desktop)	Yes	79	high	source	2
Firefox (Desktop)	No	—	high	source	3
Firefox (Android)	No	—	high	source	45
Safari (macOS)	No	—	high	source	6
Safari (iOS)	No	—	high	source	78
Samsung Internet	Yes	9.0	high	source	9
WebView (Android)	Yes	67	high	source	10

1. Derived by browser-compat-data mirroring from Chrome.
2. Derived by browser-compat-data mirroring from Chrome.
3. No Firefox support is recorded in browser-compat-data.
4. No Firefox for Android support is recorded in browser-compat-data.
5. Derived by browser-compat-data mirroring from Firefox.
6. No Safari support is recorded in browser-compat-data.
7. No Safari on iOS support is recorded in browser-compat-data.
8. Derived by browser-compat-data mirroring from Safari.
9. Derived by browser-compat-data mirroring from Chrome Android.
10. Derived by browser-compat-data mirroring from Chrome Android.

Source data: /compatibility/sensors.json · Global usage: 72 % (StatCounter 2026-05)

Source: spec · MDN · Last verified 2026-10-03 · Confidence: high (computed from sources)

Per MDN’s browser-compat-data, Gyroscope matches Accelerometer, while Magnetometer and AmbientLightSensor are available in Chromium only behind the #enable-experimental-web-platform-features flag — feature-detect the interface you actually use rather than assuming one blanket status.

How to use it

A sensor is constructed with an optional frequency, then started; readings arrive on the reading event:

const acl = new Accelerometer({ frequency: 60 });
acl.addEventListener('reading', () => {
  console.log(`Acceleration along the X-axis ${acl.x}`);
});
acl.start();

Per MDN, using a sensor also requires the user to grant permission through the Permissions API (permission names vary by sensor, e.g. 'accelerometer', 'magnetometer', 'ambient-light-sensor'), and the feature “is available only in secure contexts (HTTPS).”

How to detect it at runtime

Check for the specific interface on window and return an explicit fallback when it is missing, rather than letting the constructor throw:

function startAccelerometer(onReading) {
  if (!('Accelerometer' in window)) {
    // Fallback: the interface isn't exposed here, so no motion-driven UI —
    // the caller keeps its static layout.
    return null;
  }
  try {
    const sensor = new Accelerometer({ frequency: 60 });
    sensor.addEventListener('error', (event) => {
      console.error(`Sensor error: ${event.error.name}`);
    });
    sensor.addEventListener('reading', () => onReading(sensor));
    sensor.start();
    return sensor;
  } catch (error) {
    // Per MDN, the Accelerometer() constructor throws a SecurityError when a
    // Permissions Policy set on the server blocks the feature.
    console.error(`Could not start sensor: ${error.name}`);
    return null;
  }
}

Practical checklist

• Per MDN, the Accelerometer interface “is available only in secure contexts (HTTPS)”.
• Feature-detect the specific interface ('Accelerometer' in window, etc.) — per MDN’s browser-compat-data the Chromium flag requirement differs between Accelerometer / Gyroscope and Magnetometer / AmbientLightSensor.
• Handle the sensor’s error event — per MDN, once it fires the sensor “becomes idle and stops reading values” until it is restarted.
• A SecurityError from the constructor means a Permissions Policy is blocking the feature, per MDN’s documented exception for Accelerometer().
• Per MDN’s browser-compat-data, Firefox and Safari implement none of these interfaces, so design a real fallback path rather than a dead feature.

Where to go next

For the full reference (permission names, error handling, per-sensor differences), see Generic Sensor API.

See also Geolocation for another device-capability entry in this explorer.

← Back to the Compatibility explorer.