hardwareConcurrency and deviceMemory: Device Class in Two Numbers

Two one-line reads in JavaScript tell a page roughly how powerful your device is: how many logical processors it has, and about how much RAM. Neither number is rare on its own. Together they sort a visitor into a device class: a budget phone, an office laptop, a workstation. This post covers what each value means, how browsers deliberately blur them, and why their main use is checking whether a claimed device is believable.

Key Takeaways

• navigator.hardwareConcurrency reports the number of logical processors available to run threads, and a browser may report a lower number than the machine really has.
• navigator.deviceMemory reports approximate RAM in GiB, rounded to a power of two and clamped to implementation-defined bounds. It is a Chromium-side API; do not expect it in every browser.
• Each value is low-entropy by design. Their weight comes from combining with screen size, GPU and platform, which is the arithmetic in fingerprint entropy and anonymity sets.
• They are most useful as consistency checks: a device that claims one class in its user agent and reports another here has told two stories.
• BrowserInsight shows both values exactly as your browser reports them, and its bot check applies a plain range test, not a comparison against your user agent.

Why These Two APIs Exist

Neither was created for tracking. Both let a page adapt to the device it runs on.

hardwareConcurrency exists to size a pool of Web Workers. MDN's hardwareConcurrency page shows exactly that: one Worker per reported logical processor. The Device Memory specification, W3C Device Memory, describes a "device-class signal" used to serve a lighter version of a site to low-end devices and to normalize performance metrics, so that a long task on a weak device is read differently from one on a strong device.

hardwareConcurrency: Logical Processors, Not Cores

MDN defines the value as the number of logical processors available to run threads on the user's computer, between 1 and the number potentially available to the browser. Two details matter:

• Logical, not physical. A four-core CPU that runs two threads per core can report eight. The number you see is not a core count.
• Possibly reduced. MDN states that the browser may report a lower number to represent more accurately how many Workers can run at once, so it is not an absolute measurement of the hardware. We do not list per-browser reduction rules here, because MDN does not pin them down and they change; check the compatibility table on that page for your target browsers.

Common values on real machines are small powers and multiples such as 4, 8, 12 or 16, which is why the number alone narrows little. A reading of 2 and one of 24 still split visitors, but into broad groups.

deviceMemory: Coarse on Purpose

The Device Memory API is built to be imprecise. According to the specification and MDN's deviceMemory page:

• The value is the physical memory rounded to a power of two, expressed in GiB, so you get a figure such as 2, 4 or 8 and not "7.6".
• It is then clamped to implementation-defined lower and upper bounds, chosen so that rare very-low and very-high memory sizes are not exposed. The spec says implementations may adjust the bounds over time and that they may differ by device type. MDN's own example uses a browser that does not report below 2 or above 32, giving 2, 4, 8, 16 or 32. That is an illustration, not a universal rule.
• It is available only in secure contexts (HTTPS).

Servers can also receive the same figure without running any script, through the Sec-CH-Device-Memory client hint. It is opt-in: the server must first send Accept-CH: Sec-CH-Device-Memory, and MDN marks the header as experimental. For how this header path fits with other hints, see User-Agent Client Hints.

Support is uneven. deviceMemory is not exposed by Safari or Firefox, so a missing value is normal there and is shown as "unknown", never as a red flag. The absence itself still tells a page something about the engine.

Why Two Small Numbers Still Matter

Take a typical combination of values and ask how many visitors share it. Plenty do, which is exactly why neither value is a good identifier alone. The risk appears when they are added to dozens of other signals, such as screen geometry, GPU renderer and platform; each one cuts the crowd further. The anonymity-set arithmetic shows how a handful of low-entropy bits add up, and the browser fingerprinting guide lists where these two sit among the rest.

Where They Matter More: Consistency

A weak identifier can still be a strong lie detector. The values should fit the device the browser claims to be:

• A desktop Windows user agent that reports 2 logical processors and the lowest memory bucket is unusual, though not impossible, for a modern machine.
• A mobile user agent reporting dozens of logical processors, or a memory figure far beyond any phone, suggests an emulated or virtualized environment.
• An iPhone user agent that also supplies a deviceMemory value would be odd, since WebKit does not expose the API.
• Hundreds of "different" visitors with the identical core count, memory bucket and screen size look like one image cloned many times. That is the aggregate pattern behind cloud phone detection.

None of these is proof on its own. They are weighed with other contradictions such as the impossible GPU and OS pairings in fingerprint hardware mismatch, the automation hints in headless browser detection, and the general principle in fingerprint consistency.

How Privacy Tools Handle Them

Hardening modes replace exact hardware values with generic ones so that every user in the group looks alike. Firefox's resist-fingerprinting mode, for example, spoofs navigator.hardwareConcurrency to a fixed value; resist fingerprinting explained covers the trade-offs, including the occasional site that breaks on an unexpected value. The aim is a bigger anonymity set, not a believable fake: a random invented number can be as distinctive as the truth. On the header side, browsers only send Sec-CH-Device-Memory after the server opts in, and the value is already coarse.

What BrowserInsight Actually Does

Two things, stated plainly. The fingerprint check shows hardwareConcurrency and deviceMemory exactly as your browser reports them, and shows "unknown" where an API is absent. The bot detection page runs a hardware_limit plausibility check that only tests whether present values fall inside a sane range (cores 1 to 64, memory up to 64 GiB). It does not compare them against your user agent or GPU. All collection runs in your browser and nothing is sent to a server.

Frequently Asked Questions

Is hardwareConcurrency the number of CPU cores? No. It counts logical processors, which can be twice the physical core count, and a browser is allowed to report a lower number.

Why is my deviceMemory never 6 or 12? The value is rounded to a power of two before it is reported, so in-between sizes land on a neighbouring bucket.

Can a site read my RAM without JavaScript? Only through the Sec-CH-Device-Memory client hint, and only if the server asked for it with Accept-CH and your browser supports it.

Is this enough to track me? Not by itself. It becomes useful to a tracker only when combined with many other signals.

Conclusion

hardwareConcurrency and deviceMemory are deliberately modest signals: a coarse processor count and a rounded memory bucket. Their practical value is in checking that a claimed device is plausible, and in the extra bits they add to a larger fingerprint. Check what your own browser reports on the fingerprint check, and see whether the rest of your setup tells the same story.