What Is Battery Fingerprinting? – Definition and How It Works

Learn how the Battery Status API was used for tracking, why browsers restricted it, and what it still reveals.

Battery fingerprinting uses the Battery Status API — charge level, charging state, and time estimates — as an identifying or automation-detecting signal.

1. The API

const b = await navigator.getBattery();
b.level            // 0.0 to 1.0
b.charging         // boolean
b.chargingTime     // seconds until full, or Infinity
b.dischargingTime  // seconds until empty, or Infinity

2. Why It Became a Privacy Problem

Battery level combined with discharge time was, at its most precise, effectively a short-lived unique identifier. Two facts made it powerful:

• High precision. Early implementations reported level to many decimal places, giving a value shared by very few devices at any moment.
• It changes slowly and predictably, so the same device is recognisable across page loads for minutes at a time.

That allowed re-identification across contexts where cookies were unavailable — including across private browsing sessions and between sites. Research demonstrating this led directly to the API being restricted.

3. What Browsers Did About It

The API's history is a useful example of a fingerprinting surface being closed:

• Precision reduced — level rounded to coarse steps rather than fine decimals.
• Removed entirely from some browsers, notably Firefox for web content.
• Restricted to secure contexts and, in places, to top-level frames.
• Availability narrowed, so it is now largely a Chromium-family API.

The result is a much weaker signal than it once was, and one whose availability varies by browser.

4. What It Still Reveals

Even coarsened, it carries information:

The last row is the automation-relevant one. A headless browser on a server reports a permanently full, permanently charging battery — which is exactly what a desktop reports, and therefore not damning on its own.

5. The Consistency Angle

As with every fingerprint surface, contradiction is the strong signal. A session claiming to be a mobile device via user agent, screen size, and touch support, while reporting a permanently full battery on mains power, is inconsistent — real phones discharge.

So the risk is not the battery value itself but a battery value that disagrees with the claimed device class.

6. Practical Guidance

1. Do not spoof it unless the whole profile demands it. The API's absence or a desktop-like reading is unremarkable.
2. If claiming a mobile device, be aware of the mismatch — a static full battery undermines a mobile profile.
3. Do not add the API where the claimed browser lacks it. Providing a Battery API while claiming Firefox is a contradiction, not a disguise.
4. Treat it as low-value relative to address reputation, TLS fingerprint, and rendering signals.

7. The Broader Lesson

Battery fingerprinting is worth understanding less for its current strength than as the clearest case study in how these surfaces evolve: a benign convenience API turned out to be a tracking vector, researchers demonstrated it, and browsers coarsened and then removed it.

The same pattern has repeated across other APIs, which is why fingerprinting surfaces are a moving target and why any hardcoded assumption about what a browser exposes decays.

8. Summary

Battery fingerprinting reads charge level, charging state, and time estimates, and was once precise enough to act as a short-lived unique identifier across contexts — which is why browsers coarsened its precision, restricted it to secure contexts, and in some cases removed it entirely.

It is now a weak signal whose main relevance is consistency: a permanently full, permanently charging battery is normal for a desktop and contradicts a claimed mobile profile, so leave it alone rather than spoofing it.

Potential Related Glossary

• Browser Fingerprints
• Headless Browser
• DataDome
• Web Crawling