Battery Status API: Browser Support, Privacy, Use Cases

What is the Battery Status API?

The Battery Status API is a W3C JavaScript API that lets a web page read a device's charge level, charging state, and time-to-full or time-to-empty estimates. The API entry point is navigator.getBattery(), which returns a Promise that resolves with a BatteryManager object exposing four properties and four change events.

Which browsers does the Battery Status API support?

Every Chromium-based browser supports the Battery Status API on desktop and Android, while Firefox removed it and Safari has never shipped it on macOS or iOS, leaving global support around 76%.

What are the key features of the Battery Status API?

The Battery Status API is built around one Promise-returning entry point, a BatteryManager object with four read-only properties, and four change events. Every value is reactive, so a single getBattery() call gives a page everything it needs.

• navigator.getBattery(): Returns a Promise that resolves with a BatteryManager. The page calls it once and reuses the resolved object for the rest of the session.
• BatteryManager.charging: A boolean that is true when the device is plugged in and charging. It flips on the chargingchange event when the user plugs or unplugs the cable.
• BatteryManager.level: A number from 0.0 to 1.0 that represents the current charge as a fraction. Multiply by 100 to display a percentage in the UI.
• BatteryManager.chargingTime: Seconds until the battery is full. The value is 0 when the battery is already full and Infinity when the device is not charging.
• BatteryManager.dischargingTime: Seconds of runtime left at the current draw. The value is Infinity when the device is charging or when the OS cannot estimate it.
• chargingchange, levelchange, chargingtimechange, dischargingtimechange events: Fire on the BatteryManager when each underlying value changes, so a page can react without polling.
• Secure-context gate: Chrome 103+, Edge, Opera, and Samsung Internet expose navigator.getBattery only on HTTPS and on http://localhost. Plain HTTP pages get an undefined entry point.
• Window-only access: The API is exposed on the Window navigator, not on Worker or ServiceWorkerGlobalScope, so battery-aware code lives on the main thread.

Paste this snippet into the DevTools console of Chrome, Edge, Opera, or Samsung Internet over HTTPS. The console logs the current battery state and re-logs whenever any of the four values change.

// Paste this into the DevTools console of Chrome, Edge, Opera, or Samsung Internet over HTTPS.
// Safari and Firefox do not expose navigator.getBattery, so the script logs a fallback message there.
if ("getBattery" in navigator) {
  navigator.getBattery().then((battery) => {
    const log = () => {
      console.log("Charging:", battery.charging ? "yes" : "no");
      console.log("Level:", Math.round(battery.level * 100) + "%");
      console.log("Charging time:", battery.chargingTime, "seconds");
      console.log("Discharging time:", battery.dischargingTime, "seconds");
    };

    log();

    battery.addEventListener("chargingchange", log);
    battery.addEventListener("levelchange", log);
    battery.addEventListener("chargingtimechange", log);
    battery.addEventListener("dischargingtimechange", log);
  });
} else {
  console.log("Battery Status API is not supported in this browser.");
}

What are the privacy and security concerns with the Battery Status API?

The Battery Status API is the textbook fingerprinting case in modern web standards work. The combination of level, chargingTime, and dischargingTime is precise enough to re-identify a single device across origins and across private-browsing sessions, which is why Firefox dropped it and Safari never shipped it.

• Fingerprinting through value precision: The unrounded level and time values create a short-lived but highly unique tuple. Two scripts on different origins reading the same tuple within seconds can confidently link the visitor.
• Re-identification across private mode: A user who switches to private browsing keeps the same battery state, so the API can defeat the isolation that private mode is supposed to provide.
• Chromium precision rounding: Chrome and Chromium derivatives now round level to two decimal places and clamp chargingTime and dischargingTime to coarse buckets, which lowers the fingerprint entropy without breaking honest use.
• HTTPS-only from Chrome 103: Calling getBattery() from an http:// origin returns undefined. The secure-context gate stops passive network observers from reading the values off the wire.
• No user permission prompt: Unlike the Geolocation or Notifications APIs, the Battery Status API does not show a permission dialog, which is part of why privacy researchers pushed back on it.
• Permissions-Policy gate for iframes: Chromium browsers honor a battery directive in the Permissions-Policy header, so a page can block third-party iframes from reading battery state.

What are the use cases of the Battery Status API?

The Battery Status API is the right tool when a web app needs to throttle expensive work on a low battery or warn the user before unsaved changes vanish. Production sites use it as a progressive enhancement, not a hard dependency.

• Lower video and animation quality on low battery: Streaming and game sites step down resolution, frame rate, or particle effects when level drops below 20% on Chromium-based browsers.
• Auto-save before shutdown: Web apps like Google Docs, Notion, and Figma can flush a draft to storage when dischargingTime is short and charging is false, so the user does not lose work.
• Defer background sync: Progressive web apps pause non-critical background fetches and reschedule them once charging flips to true, which keeps the device cool and the battery healthier.
• Battery-aware push intervals: Chat and email PWAs lengthen their polling interval when the device is unplugged and the level is low, then snap back to fast polling on charge.
• Show charge state in dashboards: Kiosk and digital-signage web apps display a small battery indicator in a corner so on-site staff can swap a tablet before it dies.
• Throttle WebGL and WebRTC sessions: 3D web apps and video-call clients lower the GPU and encoder settings when the host laptop is unplugged and below 30% to extend session life.
• Adaptive PWA install prompts: A PWA can hold back its install prompt on a low battery so the prompt does not interrupt a user already trying to conserve power.

What are the known issues with the Battery Status API?

The Battery Status API is well-supported on Chromium, but the rough edges show up around the Safari and Firefox gap, the rounded values, and the cases where the OS hands the browser stale or sentinel data.

• No Safari or Firefox path: Roughly a quarter of global users land on Safari or Firefox and get undefined for navigator.getBattery, so every battery-aware feature must be a progressive enhancement, not a dependency.
• Infinity sentinel values: chargingTime is Infinity on every unplugged device, and dischargingTime is Infinity on every plugged device or when the OS cannot estimate it, so naive Math.min calls explode.
• Rounded level on Chromium: Chromium browsers now snap level to two decimal places, so a UI that displays single-percentage steps will visibly jump from 87% to 86% rather than tick smoothly.
• HTTPS-only from Chrome 103: Older code that ran on http://intranet pages stopped working on Chrome 103 and later. Move every battery-aware page to HTTPS or to localhost.
• No worker access: A Service Worker cannot read battery state, so a background sync handler that wants to defer work on low battery has to message the page first.
• Cross-origin iframe blocking: A Permissions-Policy header that omits the battery directive blocks iframes from reading values, which surprises ad and widget integrations on partner sites.
• Desktop without a battery: A wired desktop returns charging: true, level: 1, chargingTime: 0, dischargingTime: Infinity. Code that branches on level alone treats every desktop as a fully charged laptop.

In my experience, the trap that bites every Battery Status integration once is the dischargingTime: Infinity case on a charging laptop. A naive "warn the user when less than 600 seconds remain" check fires on a desktop with no battery if you forget to filter Infinity out first. Branch on charging before you read dischargingTime and the surprise goes away.

Citations

All Battery Status API version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - Battery Status API: developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API
• MDN Web Docs - BatteryManager interface: developer.mozilla.org/en-US/docs/Web/API/BatteryManager
• MDN Web Docs - Navigator.getBattery(): developer.mozilla.org/en-US/docs/Web/API/Navigator/getBattery
• W3C Battery Status API Recommendation: w3.org/TR/battery-status
• W3C Battery Status API editor's draft: w3c.github.io/battery
• Chrome Platform Status - Battery Status API: chromestatus.com/feature/4537134732017664
• Google Chrome samples - Battery Status API demo: googlechrome.github.io/samples/battery-status
• Mozilla Bugzilla - Remove Battery Status API tracking bug: bugzilla.mozilla.org/show_bug.cgi?id=1313580
• Mozilla Hacks - Battery Status API removal context: hacks.mozilla.org/2016/11/dont-track-me-bro
• Chrome for Developers - Permissions-Policy and battery: developer.chrome.com/docs/privacy-security/permissions-policy