Battery and CPU core fingerprinting explained

Every anti-detect browser profile screen has a field for CPU cores and, on older builds, one for battery status. Most people click through it without thinking about what the number actually does once it leaves the settings panel. I run real proxy and cloud-phone farms and test these browsers against the same detection scripts that ad networks, banks, and social platforms run, so I want to walk through what these two signals actually measure, why they got added to fingerprinting scripts in the first place, and where spoofing them helps or falls apart.

What hardwareConcurrency actually tells a website

navigator.hardwareConcurrency is a JavaScript property that returns the number of logical processors your browser thinks it has access to. It is not a guess or a fingerprint hash, it is a direct read of your machine’s reported thread count: 4, 8, 12, 16, 24, whatever your CPU exposes. Any page can read it with one line of code, no permission prompt, no user gesture required.

On its own, the number has low entropy. Millions of laptops report 8. But it never travels alone. Fingerprinting scripts combine it with navigator.deviceMemory (an approximate, deliberately rounded RAM figure that Chromium caps at 8GB even on machines with far more), screen resolution, GPU renderer string from WebGL, and timezone. Once you stack five or six coarse signals together, the combination narrows fast. A script doesn’t need hardwareConcurrency to identify you by itself, it needs it to rule out matches and shrink the pool of plausible real devices down to a handful.

This is also why the value matters more for consistency checks than for uniqueness. A detection system doesn’t ask “is 8 cores rare.” It asks “does 8 cores make sense given everything else this session is telling me.”

The battery API: a fingerprinting vector browsers had to walk back

The Battery Status API (navigator.getBattery()) is older and its history explains a lot about how fingerprinting defenses evolve. When it shipped, it exposed charging state, current charge level, and estimated time to full charge or empty, all with a lot more decimal precision than any UI actually needs. Researchers found in 2015 that the combination of charge level and discharge time estimates changed often enough, and precisely enough, to let a site re-identify the same laptop across visits even after the user cleared cookies, switched browsers, or used private mode. The battery reading became a short-lived tracking cookie that lived in hardware state instead of storage.

Because of that research, browser vendors backed away from it. Firefox pulled default support for the API on desktop. Safari never shipped it for the web platform. Chromium kept getBattery() but the exposed precision and availability have been tightened over the years compared to the original spec. The practical result: a real, current Firefox or Safari session simply does not answer battery queries the way it once did, and a real Chromium browser answers with much less precision than fingerprinting scripts got used to reading a decade ago.

That history matters for anti-detect testing because it flips the battery field from “a value to spoof convincingly” into “a value whose mere presence or format can be a tell.” If a profile is impersonating Firefox but still answers a battery query with the old-style precise discharge estimate, that is not a strong fingerprint, it is a bug that no real Firefox install would produce.

Why one spoofed number doesn’t fix the picture

The core mistake I see people make with anti-detect profiles is treating hardware fields as independent knobs. Set cores to 8, memory to 16GB, done. But a detection script cross-references. If the profile reports 16 logical cores and 16GB of memory but the WebGL renderer string resolves to a low-end integrated GPU that never ships in a machine with that spec, that is an internal contradiction a script can flag without needing any history on the visitor at all. Same with a phone-shaped user agent claiming 12 hardware threads, when the vast majority of real mobile chipsets in the field report 4, 6, or 8.

The other failure mode is uniformity. If a farm spins up fifty profiles and forty-eight of them report the exact same hardwareConcurrency, deviceMemory, GPU string, and screen size because they all came from the same template with only the user agent changed, that combination becomes a fingerprint of the tooling, not of a device. Real device populations have a messy, uneven distribution of these values. A stack of identical “different” visitors is its own signal, and it is one of the easier ones for a platform to catch because it does not require tracking any single visitor over time, just comparing sessions against each other.

I do not have benchmark numbers to hand you here, and I am not going to invent a pass or fail rate for any specific product to make this piece sound more authoritative. What I can tell you from hands-on testing across tools like Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty is that they all expose hardware concurrency and (where relevant) battery fields as configurable profile parameters, and the meaningful difference between them is less about whether the field exists and more about whether the surrounding fingerprint (GPU, fonts, audio context, timing behavior) stays internally consistent with whatever OS and browser version the profile claims to be.

What consistency actually requires

If you’re evaluating any anti-detect browser on this specific axis, the questions worth asking are:

• Does the spoofed core count fall within the real-world range for the device class and OS the profile claims to be
• Does deviceMemory scale sensibly with hardwareConcurrency, since real hardware tiers pair these together
• Does the GPU renderer string match a plausible machine that would actually ship with that CPU and RAM combination
• If the profile claims to be a browser that removed or restricted the battery API, does it actually behave that way, or does it still answer old-style precise battery queries
• Across a batch of profiles, is there enough natural variance in these values, or does everything look copy-pasted from one template

None of this makes a profile undetectable, and no anti-detect vendor can honestly promise that a coherent fingerprint means an account survives a platform’s other layers of detection, like behavioral analysis, IP reputation, or account history. Fingerprinting is one detection layer among several, and hardware fields are one part of that one layer.

The honest takeaway

Battery and CPU fingerprinting exist because browsers expose more machine detail than most users realize, and because that detail turned out to be stable and specific enough to help re-identify a device. Anti-detect browsers give you the controls to change what these fields report, but the value of that control depends entirely on whether the rest of the profile agrees with the story those two numbers are telling. A spoofed core count that contradicts your GPU string, your memory value, or your claimed OS is worse than not spoofing it at all, because now you’ve handed the script a contradiction instead of an ordinary device.

If you want more breakdowns like this on how specific fingerprint signals actually work, and hands-on notes from testing anti-detect browsers against real detection scripts, you can find them on the home page.

Get new guides and videos first — join the Telegram channel.