Hardware Concurrency and Device Memory: CPU and RAM Signals in the Browser

The browser will happily tell you how many logical CPU cores a machine has and roughly how much RAM it carries. These two numbers seem mundane, but they cut the device population into useful slices and expose a favorite mistake of automation operators.

The two direct signals

navigator.hardwareConcurrency returns the number of logical processors, typically 4, 8, 12, or 16 on consumer hardware. navigator.deviceMemory returns approximate RAM in gigabytes, bucketed to coarse values like 0.5, 1, 2, 4, and 8 to limit precision. Both are trivial to read and require no permission.

Neither is high entropy alone. There are only a handful of common core counts and even fewer memory buckets. Their value comes from combination with everything else and from a specific failure mode: spoofed environments frequently report values that do not match the rest of their story.

The tells that expose automation

Headless and virtualized environments betray themselves through these fields more often than operators expect:

• Implausible core counts: a server-grade hardwareConcurrency of 32 or 64 paired with a mobile user agent is a contradiction. Real phones report modest core counts.
• Default cloud values: many cloud instances and CI runners report a specific small core count that clusters suspiciously across supposedly distinct visitors.
• Missing deviceMemory: the API is not available in every browser, and its absence combined with a user agent that should support it hints at tampering.
• Memory-to-core mismatch: a claimed 8 cores with 0.5 gigabytes of RAM is a profile almost no real device matches.

Prynt scores the joint distribution of cores, memory, platform, and user agent. Devices that fall outside the plausible region get flagged for closer inspection.

Verifying claims with timing

Because both values are writable, a claim alone is weak. The stronger approach measures behavior. A short, carefully bounded workload that scales with available parallelism, or a measurement of how the browser schedules a handful of workers, produces timing that reflects the actual hardware rather than the reported numbers.

If a device claims 16 cores but a parallel workload shows no speedup beyond 2, the claim is suspect. Prynt keeps these probes deliberately light, because heavy benchmarks drain battery and annoy users, but even a brief timing signal is enough to catch the crudest spoofs. The measured behavior becomes a check against the declared hardwareConcurrency.

Battery and related hardware hints

The old Battery Status API once added entropy through charge level and charging state, but most browsers have restricted or removed it for privacy reasons. Prynt does not rely on battery data where it has been deprecated. Instead it leans on the stable, still-exposed hardware fields and their consistency with one another. Where a signal has been locked down by browser vendors, chasing it is wasted effort and a privacy risk; we focus on what remains reliably available.

How Prynt uses these signals

Hardware concurrency and device memory are two of the more than 20 signals feeding Prynt’s stable visitorId. Their main jobs are coarse device-class separation and consistency checking. When cores, memory, GPU limits, and screen metrics all agree on a device tier, confidence rises. When they contradict, the session earns scrutiny.

This kind of cross-signal reasoning is central to Prynt’s bot detection, where a single implausible core count rarely decides anything but a stack of small inconsistencies reliably separates real browsers from automation. Because the correlation runs in our cloud, an operator who patches one field still has to make every other signal agree.

Clustering across sessions

The individual coarseness of these fields becomes an advantage when you look across many sessions instead of one. Legitimate traffic spreads across a natural distribution of core counts and memory tiers. A fraud ring or a bot fleet, by contrast, often runs on identical cloud instances, so the same exact hardwareConcurrency and deviceMemory pair repeats far more often than chance allows. That over-representation of one hardware profile, especially a default cloud configuration, is a population-level signal no single visitor reveals. Prynt surfaces these clusters by correlating hardware fields across its reputation network, turning two low-entropy numbers into a meaningful indicator when the same rare-in-the-wild but common-in-the-cloud profile shows up on hundreds of accounts at once.

Practical recommendations

• Read both values but treat them as coarse class indicators, not identifiers.
• Flag impossible combinations of cores, memory, and device class.
• Add a light timing probe to verify concurrency claims without harming battery life.
• Do not depend on deprecated hardware APIs like Battery Status where browsers have removed them.

CPU and RAM signals will never fingerprint a device on their own, but they are cheap, permission-free, and remarkably good at catching environments that lie about what they are running on.

Try Prynt free and see your device’s hardware profile resolve live in the playground.