The Battery Status API exposes more than a percentage
A battery icon feels like ordinary device information. Yet when a website can read whether a device is charging, its current level, and estimates for time remaining, those values become part of the browser's observable surface. The Battery Status API was designed for useful purposes: saving work before power runs out, reducing background activity, or choosing a lighter experience on a low battery.
That practical idea also created a privacy question. A changing combination of battery values can help distinguish one browser session from another. Modern specifications and browser implementations therefore treat battery information more cautiously than early versions of the web platform did.
What the Battery Status API reports
The API begins with navigator.getBattery(). When supported, it resolves to a BatteryManager object with four main signals: whether the device is charging, the charge level from zero to one, the estimated charging time, and the estimated discharging time. Websites can also listen for events when those values change.
The MDN Battery Status API reference describes sensible examples. A web app could reduce frequent network checks when a laptop is running low, or save a document before shutdown. These adaptations can improve reliability without asking the user to monitor power manually.
The API is available only in secure contexts in supporting browsers, and MDN marks it as limited availability because some widely used browsers do not implement it. Developers should feature-detect it and design the page to work normally when no battery data is available.
Why battery readings became a privacy concern
A single reading such as 62 percent is not a permanent identity. The concern appears when level, charging state, and time estimates are observed together and updated over time. That pattern may remain recognizable long enough to connect activity across pages or sessions, especially when combined with screen size, language, hardware hints, and other signals.
This is the same cumulative effect explained in our guide to browser fingerprinting without cookies. Each detail may look unremarkable. The combination can narrow the crowd until one browser becomes easier to recognize.
Battery estimates may also reveal context. A switch from discharging to charging suggests that the device was connected to power. Fast changes can hint at device condition or workload. None of these inferences is guaranteed, but privacy engineering must consider what repeated measurements make possible—not only what one value says in isolation.
How the specification reduces exposure
The current W3C Battery Status API specification includes defensive defaults. If the browser cannot or chooses not to report battery status, it can return values that resemble a fully charged device connected to power. That keeps sites functional while revealing less about the actual machine.
The specification also makes battery access a policy-controlled feature. Its default Permissions Policy allowlist is self, so cross-origin embedded content does not automatically receive the same access as the top-level site. Site owners can restrict the feature further through an HTTP header.
The editor's draft explicitly warns against high-precision readouts because precision adds fingerprinting entropy. Rounding or coarsening the values makes many devices look alike. That design principle appears elsewhere in the platform: the Device Memory API reports broad categories rather than an exact RAM total.
Why browser support differs
Web standards are negotiated through implementation experience as well as written specifications. A useful capability can be limited when vendors judge that its benefit does not justify its privacy surface. That is why an API may remain documented while support varies significantly among browser engines.
Limited support also changes the value of battery-aware design. If an application must provide a reliable fallback anyway, developers should ask whether reading battery state is essential. Often it is enough to respond to user choices, page visibility, reduced-motion preferences, or measured performance instead of inspecting power conditions.
For users, the important lesson is not that battery data is uniquely dangerous. It is that apparently minor device signals can become identifying when collected at scale. Good browsers reduce precision, partition access, or omit a capability when the privacy tradeoff is weak.
What website developers should do
- Make battery-aware behavior an optional enhancement, never a requirement.
- Feature-detect
navigator.getBatteryand handle rejection or absence cleanly. - Avoid logging battery readings for analytics, advertising, or user profiling.
- Do not poll more frequently than the product genuinely needs.
- Use Permissions Policy to prevent unnecessary access from embedded third parties.
- Explain the benefit if battery state materially changes the experience.
Teams should also review battery access alongside other permissions and device APIs. Our practical guide to browser permissions explains how to audit which capabilities a site requests and why.
What users can realistically control
There is usually no prominent battery permission prompt. Control mostly comes from browser choice, implementation safeguards, and tracker blocking rather than a per-site decision. Private browsing may apply additional restrictions, but behavior differs between browsers and versions.
Keeping the browser updated matters because privacy mitigations evolve. Tracker blocking also reduces the number of third-party scripts able to combine battery data with other attributes. Clearing cookies alone is not a complete answer: fingerprinting techniques are specifically valuable to trackers because they can work without durable browser storage.
The Battery Status API is a useful case study in responsible web design. Device awareness can make software considerate, but it should not quietly become an identity signal. The safest implementation gives sites only the precision they need, keeps third parties out by default, and leaves the experience intact when the data is unavailable.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.