CPU, memory, and battery: your hardware fingerprint

The short version

Your browser can tell a website a few things about the machine itself: roughly how powerful your processor is, roughly how much memory it has, and in the past even your battery level. Each fact is coarse and shared by millions of people, but combined with everything else a site learns, it helps build a recognizable profile. This guide explains what's exposed, why most of it is hard to hide, and the few honest steps that help.

What's actually happening

Imagine someone guessing which car you drive. "It has four wheels" tells them nothing. "Mid-size SUV, silver, roof rack, dealer sticker" starts to narrow it. Your hardware traits work the same way: individually vague, collectively useful.

The two big ones a browser hands out are your processor core count (reported as a number like 4, 8, or 16) and a rough memory size (reported in round steps like 4 or 8 gigabytes, never the exact amount). Older browsers also exposed your battery charge level and whether you were plugged in, which was surprisingly identifying because the exact percentage changes slowly and uniquely. Browsers have since locked most of that down.

Why it matters to you

• These numbers help trackers tell your device apart from others, with no cookie and no sign-in.
• They're stable. Your core count and memory don't change day to day, so they're a reliable anchor for recognizing you.
• This is one of the harder areas to hide. There's no simple switch in Chrome or Safari that turns it off.

How to reduce it

Be realistic: you can't change how many cores your computer has, and most browsers report it. What you can do is choose a browser that masks or standardizes these values.

Use a browser that limits it (best option)

• Tor Browser reports a standardized, capped core count and hides memory size, so you look like the crowd. This is the strongest choice.
• Firefox with its fingerprinting protection turned on (Settings, then Privacy & Security) caps and standardizes these values. Firefox also never exposed the memory reading in the first place.
• Brave reduces and slightly randomizes some hardware signals by default under its Shields.
• Safari does not expose the memory reading and strips the battery data. It's better here than stock Chrome.

What doesn't help (so you don't waste effort)

• Clearing cookies or using incognito: these traits are read fresh each time regardless.
• A VPN: it hides your location and address, not your hardware readings.
• Most "anti-fingerprint" browser extensions: they often make you more unusual, not less. See our extensions guide.

Check your battery exposure

Good news: current Firefox, Safari, and Brave no longer expose the battery to ordinary websites. If you're on a recent version, there's nothing to do. If a very old browser still leaks it, simply updating to the latest version fixes it.

How to check it worked

Run this test again in Tor Browser or Firefox with protections on. You should see a capped, tidy core count (often 2) and no memory reading at all. If the battery line previously showed a percentage and now shows "not available," that part is fixed.

If your result was already good

If you graded well, your reported hardware values are common ones that don't single you out, which is exactly what you want, and there's nothing to change. Keep your browser updated so battery and similar leaks stay closed, and know that a very common core count and memory size (like 8 cores, 8 GB) is a good thing here, not a bad one. If you switch to a brand-new high-end machine, it's worth re-checking, since unusual specs can make you stand out.

Want to go further?

The Advanced version names the exact properties (navigator.hardwareConcurrency, navigator.deviceMemory, the old Battery Status API), explains the client-hint headers that leak the same data before any script runs, and covers why timing tricks can sometimes verify a spoofed core count.

Summary

Hardware exposure in the browser is dominated by three signals: navigator.hardwareConcurrency (logical core count), navigator.deviceMemory (bucketed RAM, Chromium-only), and the now largely removed Battery Status API. Each is low-to-medium entropy individually, but stable and cheap to collect, making them durable fingerprint anchors. Mitigation means capping or standardizing these values (Tor/Firefox RFP) rather than erasing them, and understanding that the same data also leaks via Client Hints headers server-side.

What's actually being read

• navigator.hardwareConcurrency — number of logical processors. Typical values cluster at 4, 8, 12, 16. Low entropy by itself, but it correlates with device class and pairs tightly with deviceMemory and GPU strings. Scripts can also verify a reported value by spawning Web Workers and timing contention, so naive spoofing that only overrides the property can be caught.
• navigator.deviceMemory — approximate RAM in GiB, rounded down to a value from a fixed set (0.25, 0.5, 1, 2, 4, 8). Chromium-only, so an undefined result itself signals Firefox/Safari/Tor. The same data is exposed server-side via the Device-Memory Client Hint header, meaning it can be collected before any JavaScript executes.
• Battery Status API (navigator.getBattery()) — once returned charge level (0–1 at high precision), charging state, and charge/discharge times. The precise level drifts slowly and was effectively a short-lived unique ID, and could even bridge same-origin private/normal sessions. Firefox removed it, Safari never shipped it, and Chromium restricted it; treat any site still reading it as using a legacy surface.
• Related: WebGL renderer/vendor strings (GPU model), maxTouchPoints, and User-Agent Client Hints (platform, architecture, bitness, model) round out the hardware picture.

Why it matters

These values are attractive to trackers precisely because they're stable and permission-free. They don't reset with cookie clearing or incognito, they're consistent across a device's sessions, and several (deviceMemory, platform, architecture) are also available as HTTP request headers, so collection can happen passively. On their own they rarely identify; as part of a joint fingerprint they meaningfully shrink the anonymity set and help re-link a session after more volatile signals change.

How to reduce it, per approach

Tor Browser (strongest)

1. Reports a standardized, capped hardwareConcurrency (commonly 2) regardless of real cores.
2. Does not expose deviceMemory, and the Battery API is unavailable.
3. Also standardizes UA and Client Hints, closing the passive/header leak that per-site JS tweaks miss. Don't defeat it by enabling exotic flags.

Firefox with RFP / fingerprinting protection

1. Set privacy.resistFingerprinting = true (about:config) for full Tor-derived behavior, which spoofs/caps hardwareConcurrency and keeps values generic.
2. Firefox has not implemented navigator.deviceMemory at all, so that bucket is simply absent.
3. dom.battery.enabled is off/removed; the Battery API is not exposed to content.
4. Trade-off: RFP's broad changes (UTC time, generic UA, canvas prompts) can break sites; the lighter "fingerprinting protection" mode is less disruptive but narrower.

Brave

1. Shields "Block fingerprinting" (Standard, default on) reduces and perturbs several device/hardware surfaces and caps some values.
2. Still Chromium-based, so deviceMemory and Client Hints behavior tracks Chromium's; verify in the test rather than assuming.

Stock Chrome / Edge (harm reduction)

1. No first-class toggle to mask hardwareConcurrency or deviceMemory. Enterprise policy or flags can disable some Client Hints, but this is fragile and itself unusual.
2. Keep the browser current so the Battery API and other legacy surfaces stay restricted.
3. Accept that on stock Chromium these values are exposed by design; switch browsers if this vector matters to your threat model.

Avoid naive spoofing extensions

Extensions that override navigator.hardwareConcurrency via a content script often fail Worker-timing cross-checks (reported cores don't match measured parallelism), producing an inconsistent fingerprint that's more unusual than the honest value. Prefer browser-level, coordinated mitigation (Tor/RFP) over point overrides.

How to verify

Re-run this test and open the console to read the raw values:

• navigator.hardwareConcurrency — expect a capped number (e.g., 2) under Tor/RFP.
• navigator.deviceMemory — expect undefined on Firefox/Safari/Tor; a bucketed number on Chromium.
• navigator.getBattery — expect it to be absent or to reject on hardened browsers.

Cross-check with a fingerprint lab (EFF Cover Your Tracks, amiunique.org) to see the entropy each value contributes. Also inspect request headers (DevTools, Network tab) for Device-Memory, Sec-CH-UA-Platform, Sec-CH-UA-Arch, and related Client Hints to confirm the passive leak is or isn't present.

If your result was already good

A strong grade means your reported hardware values sit in common buckets and your battery surface is closed, which is the desired state, so no action is needed. Keep the browser updated so legacy APIs stay restricted, and don't bolt on spoofing extensions that would reintroduce inconsistency. Re-test after a hardware change, since unusual specs (very high core counts, unusual RAM) can push you out of the common buckets.

Want to go further?

Hardware is one layer of a joint fingerprint. Combine this with the screen/display guide (resolution, devicePixelRatio), the canvas/WebGL surfaces (GPU strings overlap with hardware here), and the extensions guide, since inconsistencies between claimed and measured capabilities are themselves a tell. The durable lesson: these values can't be made to vanish in a normal browser, so the winning move is to report common, internally consistent values (Tor/RFP) rather than exotic or contradictory ones.