How Windows battery reports become useful data
Windows can generate a detailed battery report with one built-in command:
powercfg /batteryreport
The resulting battery-report.html contains useful information, but most of it is presented as technical tables. Design capacity, full charge capacity, cycle count, usage history, and battery life estimates are all there—the difficult part is interpreting them correctly.
I built a browser-based analyzer to make that report easier to understand without sending the file to a server.
The two values behind battery health
The most common calculation compares:
- Design Capacity: the charge capacity specified when the battery was new.
- Full Charge Capacity: the maximum charge the battery can currently hold.
A simple reported-capacity estimate is:
Battery health (%) = Full Charge Capacity ÷ Design Capacity × 100
For example, a battery with a 50,000 mWh design capacity and a 42,500 mWh full charge capacity reports roughly 85% capacity health.
That number is useful context, but it is not a complete diagnosis. Runtime also depends on workload, display brightness, background activity, temperature, power settings, and calibration. Physical warning signs such as swelling, leaking, odor, or unusual heat should never be reduced to a percentage.
Parsing the report locally
The privacy requirement shaped the implementation. A battery report can reveal device and usage information, so the selected HTML file should not need to leave the user's browser.
The browser's FileReader API can read the report as text:
const reader = new FileReader();
reader.onload = () => {
const html = reader.result;
const documentCopy = new DOMParser().parseFromString(html, 'text/html');
// Extract only the battery fields needed for the result.
};
reader.readAsText(file);
No upload endpoint is required. The report is processed in memory, and the page can extract the relevant table labels and values directly.
Report formats are not perfectly consistent
The difficult part was not the formula—it was handling variations in Windows reports.
A robust parser has to account for:
- Multiple installed batteries.
- Missing cycle-count values.
- Localized or slightly different table structures.
- Capacity values containing commas and units.
- Reports where capacity history is incomplete.
- Devices that expose limited information through firmware.
Instead of assuming fixed table positions, the parser searches for known labels and then normalizes the surrounding values. When a value is missing, the interface should say that Windows did not report it rather than inventing an estimate.
Cycle count needs context
Cycle count is often misunderstood. One cycle represents cumulative use equal to 100% of the battery's capacity; it does not necessarily mean a single charge from 0% to 100%.
It is a supporting signal, not a universal pass-or-fail threshold. Two batteries with the same cycle count can have different capacity, runtime, temperature history, and physical condition.
Capacity history is more useful than one reading
A single percentage can be affected by calibration and reporting behavior. Capacity history helps reveal whether the decline is gradual or whether a sudden change deserves investigation.
The analyzer therefore treats the latest health percentage as one part of the result and presents history, cycle count, and practical next steps alongside it.
The finished tool
You can try the live Windows battery report analyzer without creating an account. It supports a generated battery-report.html file and manual capacity entry. Processing happens locally in the browser.
I also documented the small helper project and report workflow on GitHub.
The main lesson from building it was simple: extracting a number is easy; explaining its limitations clearly is the real product work.
Top comments (1)
How do you handle the health percentage when the report contains two batteries? A useful fixture would be 50,000/40,000 mWh and 10,000/5,000 mWh: averaging their percentages gives 65%, while combined full charge / combined design capacity gives 75%. Showing the per-battery values would make that choice visible.
I'd also keep a missing or zero design capacity out of the percentage calculation rather than displaying 0% health. Those would be good parser fixtures alongside the missing cycle-count case. I haven't run the analyzer; this is based on the formula and multi-battery support described here.