DeviceBenchFree battery status readout
Battery health check, and the numbers no browser has
This page reads the four values the Battery Status API exposes — charge level, whether the charger is attached, the estimated time to full and the estimated time to empty — and updates them as they change, or names your browser and says which of them it refused. Cycle count, design capacity, full charge capacity and wear percentage reach no web standard whatsoever, which puts them beyond any page: they come from the operating system, and the exact route on macOS, Windows, iOS, Android, ChromeOS and Linux is set out below. While the tab stays open it also times the whole-percent steps to give a drain rate in percent per hour, which is the one health-adjacent figure a browser can honestly produce.
- 100% free
- No signup
- 4 readable values
- 0 health fields exist
- 6 OS routes
Asking the browser for the battery…
One call, answered or refused within a frame or two.
The readout follows four events and polls nothing, so leaving this tab in the background costs the pack almost nothing while it counts.
Cycle count and wear: where they really live
None of these six paths is a web page, and that is not an oversight in this tool — the figures below have never been part of any browser API.
- macOS
- Hold Option, click the Apple menu, open System Information and choose Power. The short version is in Settings → Battery → Battery Health.
- Cycle count, condition, and full charge capacity in mAh to set against the model's rated design capacity
- Windows
- Run
powercfg /batteryreportin Terminal or Command Prompt, then open thebattery-report.htmlit writes into your user folder. - Design capacity against full charge capacity, a capacity history table by date, and a cycle count if the pack reports one
- iOS and iPadOS
- Settings → Battery → Battery Health & Charging. On iPhone 15 and later the cycle count sits separately, under Settings → General → About.
- Maximum capacity as a percentage of new, peak performance capability, and on recent models the cycle count and date of first use
- Android
- Settings → Battery on Android 16 and on Pixel 8a upward. On Samsung the reading is in Samsung Members → Support → Interactive checks → Battery.
- A state-of-health percentage and manufacture date where the hardware reports them — many older or budget devices expose neither
- ChromeOS
- Settings → About ChromeOS → Diagnostics, then the battery panel. Charge and discharge can be run there as timed tests.
- Cycle count, current charge in watt-hours, and a live discharge rate measured by the firmware rather than by a page
- Linux
upower -i $(upower -e | grep BAT), or readueventunder/sys/class/power_supplydirectly.- energy-full against energy-full-design, which is the wear figure itself, plus charge-cycles on kernels whose driver exposes it
One definition decides how to read every panel above: a cycle is 100% of the pack’s capacity discharged, in as many sittings as it takes, so two days of running from 100% down to 50% count as one cycle and not two. That is how a two-year-old laptop shows 180 cycles while a six-month-old phone shows 400, and Apple rates a current MacBook pack to still hold 80% after 1,000 of them. Everything above that panel is charge rather than capacity, and the two never meet. The rest of what a browser will admit about the machine is on the device info page.
How to check a battery from a browser
One reading, one measurement and one place to go when the browser has nothing.
Read the card, then read what it says it could not get
The card has four outcomes and only one of them is a percentage. On Chrome, Edge, Opera or Samsung Internet you get the charge level and the charging state straight away. On Firefox and Safari you get your browser named and a sentence saying there is no getBattery function to call. A third outcome names a refusal — the API is present but rejected the call, usually because the page is not on HTTPS or is inside a frame. The fourth is the half second of reading before any of that resolves, which is why the card starts neutral rather than at zero.
Leave the tab open for two level steps
The percentage moves in whole-percent jumps, so timing those jumps is the one rate a browser can measure honestly. The panel starts counting at the first step after you arrive, not at the percentage that was already on screen when the page loaded, because that one had been standing for an unknown length of time and counting from it reads low. Two steps is enough for a figure in percent per hour; on a laptop losing 8 to 12% an hour that is 10 to 16 minutes, and the tab can sit in the background for it.
Take the wear numbers from the operating system
The six-row panel gives the exact path on each platform, with your own highlighted — a menu path on macOS and iOS, one command on Windows and one on Linux, the Diagnostics app on ChromeOS. Run it, and you have design capacity, full charge capacity and usually a cycle count, which is the set a warranty claim or a resale listing is actually judged on. Copy the readout first if you want the browser-side figures in the same note.
Technical specifications
| Values the API defines | Four — level (0-1), charging (boolean), chargingTime and dischargingTime (seconds). There is no fifth field, and none of the four describes the pack's condition |
|---|---|
| Level granularity | One percent. That is the smallest change able to reach a page, and there is no fraction behind it to request — the API was coarsened on purpose |
| Time estimates | Seconds, with Infinity standing in for "no estimate" rather than for zero; chargingTime drops to 0 the moment the pack reports itself full |
| Where it answers | Chromium engines only — Chrome, Edge, Opera, Samsung Internet — over HTTPS in a top-level page. Firefox removed it in version 52 (2017); Safari has never implemented it; a cross-origin frame is refused |
| Update method | Four events: levelchange, chargingchange, chargingtimechange, dischargingtimechange. No timer polls the battery, so a backgrounded tab costs the pack nothing to keep open |
| Drain rate measured here | Percent per hour, anchored on the first level step after arrival rather than on page load, with a straight-line runtime projection from it. Two steps are needed before a figure appears — 10 to 16 minutes at a laptop's usual 8-12%/h |
| Unreadable from any browser | Cycle count, design capacity, full charge capacity, wear percentage, voltage, temperature, chemistry and serial number. No web standard carries them, on any platform |
| Data kept | None. Level steps are timestamped in memory belonging to this tab and discarded on reload; no storage is opened, and the page sends nothing back once it has finished loading |
Frequently asked questions
Why does this page say it cannot read my battery at all?
Because you are on Firefox or Safari, and neither hands a battery to web pages. Firefox shipped the Battery Status API and then withdrew it from web content in version 52, after researchers demonstrated it could be turned into a short-lived identifier; Safari never implemented it in the first place. No preference, flag or permission in either browser turns it back on for a site, and there is no fallback a page can use — the reading is absent, not blocked. Open the same page in a Chromium browser if you want the charge level, or skip to the operating-system paths, which do not care what you browse with.
Can any website read my battery health, wear or cycle count?
No, and there is no permission to grant that would change it, because the figures were never in the standard to begin with. The Battery Status API was specified with exactly four fields — level, charging, chargingTime, dischargingTime — and a health figure was never among them; the capacities behind it sit on a fuel-gauge chip inside the pack and reach the operating system over a system bus that the web platform has no bridge to. Any site showing you a wear percentage either had you type it in or has relabeled the charge level, which is the trick worth spotting: a fresh pack and a worn one both charge to 100%.
Why does the level jump straight from 68% to 67% and then sit still?
Because whole percent is the resolution you are given. Chromium rounds the value before your page sees it, so what arrives is a staircase rather than a curve, and there is no finer figure behind it to ask for. That granularity is deliberate — the original API reported the level to several decimal places, which turned it into an identifier precise enough to follow someone between sites. It is also why the drain measurement here is timed rather than sampled: the step is the only edge available to time.
The time to empty says Infinity. Is that a bug?
No — Infinity is the value the specification assigns to "no estimate available", and it is the correct answer in two ordinary situations. It is what dischargingTime reads whenever the charger is attached, and what it reads permanently on the many desktop platforms that never produce a runtime estimate for the browser to pass along. Read it as a missing answer rather than as a number; a page that renders it as 0:00, or as a battery about to die, has mistaken the sentinel for a measurement.
My Windows battery report has an empty cycle count. Where is it?
The row is present and blank on a large share of laptops, because Windows prints a cycle count only when the pack's own controller reports one and many OEM batteries never do. Use the pair above it instead: DESIGN CAPACITY and FULL CHARGE CAPACITY are in the same report, and the second divided by the first is the wear figure itself, with no cycle count required. Then scroll to the capacity history table, which lists full charge capacity by date — that is where you find out whether the loss crept in over two years or arrived in one bad month.
Does 100% maximum capacity on an iPhone mean the battery is new?
It means the pack has not yet lost a full percent of its original capacity, which is normal for the first several months and says nothing about how many cycles are behind it. Apple's figure is a rounded percentage of design capacity, and it holds at 100% for a while before it starts moving; iPhone 15 and later are rated to keep 80% of capacity after 1,000 full cycles, earlier models after 500. On those newer models the cycle count is listed separately under Settings, General, About, and it is the number to read next — 100% capacity with 700 cycles behind it is a different purchase from 100% with 40.
Can I treat the drain rate here as a health test?
It answers a neighboring question, not the same one: how fast this machine spends charge right now, rather than how much charge the pack can still hold. Screen brightness, a background build, a video call and a charging phone plugged into the laptop all move it by several percent an hour, so the figure is at its most useful as a comparison you run twice under conditions you control. Nothing about it is stored: the step timings live in this tab, and reloading the page starts the measurement again from nothing.
About the Battery Status API, and why it answers so little
The Battery Status API exists for one job: letting a page do less work when the machine is close to empty. A mail client could postpone a sync, a video player could stop prefetching, a game could drop its frame rate — all decisions that need to know “is there much charge left, and is it going up or down?” and nothing more. So the standard exposes four values and stops there. It has no field for capacity, none for cycles and none for condition, not because they were forgotten but because none of them would help a page make that decision. Asking it for battery health is asking a fuel gauge about the state of the engine; it is the same navigator surface the device info sheet reads, and it is just as deliberately shallow.
It is also the textbook case of a small reading that became an identifier. A 2015 paper by Olejnik, Acar, Castelluccia and Díaz showed that level, chargingTime and dischargingTime together take on roughly 14 million distinct combinations and change slowly, so two visits within about thirty seconds — across different sites, across a private window, through a cleared cookie jar — can be matched on the battery reading alone. Firefox withdrew the API from web content in version 52, Safari never shipped it, and Chromium kept it while narrowing it to secure top-level pages and rounding the level to whole percent. That history is why the card above names your browser before it names a number: on a large share of visits there is nothing to report, and a fabricated 0% would be worse than an empty panel. Which engine you are actually on is easy to get wrong, since every Chromium browser also says “Chrome” in its user agent — the browser info page untangles that. The parallel worth noticing is with navigator.onLine, which the connection status page has to qualify in the same way: both are browser facts narrower than the question that brings people to them.
Health, when the operating system finally gives it to you, is a ratio of two capacities: the design capacity stamped on the pack when it was made, and the full charge capacity it manages today. Divide the second by the first and you have wear directly — a pack at 4,100 mAh against a design figure of 5,000 mAh has lost 18%, whatever its cycle count says or fails to say. Neither number has ever crossed into a browser, which is why the panel above sends you to a menu or a command line rather than pretending. What the browser can add is the other axis, how fast this machine is spending charge right now, and that figure is worth most as a controlled comparison: leave this tab timing steps while the white screen field fills a second tab for twenty minutes, then repeat it with the black screen field. On an OLED panel the two rates separate sharply, because an OLED spends power per lit subpixel and a black field lights almost none. On an LCD the backlight burns the same in both cases and the rates come out level — which tells you which kind of panel you are looking at, using nothing but the staircase this API is willing to report.
What this page does with your charge level
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The charge level and the timestamps of its steps stay in this tab for as long as it is open and are discarded on reload. That is worth saying on this page in particular, because a battery reading is the exact signal the API was cut back for: it was precise enough, and shared enough between sites, to follow a visitor around. Nothing here leaves the tab, and the Copy button hands the readout to you rather than to anyone else.