Hardware fingerprinting: screen, CPU cores, device memory and GPU

A website cannot read your serial number, but it can ask your browser how big your screen is, how many CPU cores you have, how much memory your device reports, and which graphics chip is rendering the page. None of these requires permission, and none of them changes from one visit to the next. That stability is exactly what makes them valuable for tracking. This article walks through each hardware signal, shows how they combine, and explains which browser defences genuinely help.

Why hardware signals are uniquely durable

Most tracking signals are either resettable or volatile. Cookies can be cleared, IP addresses change, and a randomised fingerprint differs each visit. Hardware characteristics are the opposite: your screen resolution will be the same tomorrow, your core count will not change until you buy a new machine, and your GPU model is fixed for the life of the device. A tracker that captures these values gets an identifier that survives cookie deletion, private browsing, and even a fresh browser install, because the new install reports the same hardware.

Individually most of these values are low entropy. Their power, as always, is in combination. A common screen size shared by millions, joined with a specific core count, a particular memory tier, and an exact GPU string, can isolate a device far more sharply than any single field. The privacyscore.dev report breaks these out separately so you can see which of your hardware traits are contributing the most.

Screen geometry: resolution, colour depth, pixel ratio

The screen object exposes several values with no prompt. screen.width and screen.height give your full display resolution, while screen.availWidth and screen.availHeight subtract space taken by OS task bars and docks, which itself leaks your platform conventions. window.innerWidth and innerHeight reveal the actual viewport, and screen.colorDepth reports bit depth, typically 24 or 30.

The most underrated of these is window.devicePixelRatio, the ratio of physical pixels to CSS pixels. A standard monitor reports 1, a Mac Retina display reports 2, and many phones and high-DPI laptops report fractional values such as 1.25, 1.5, 2.625, or 3. Because the ratio depends on both the hardware panel and the OS scaling setting you chose, it is more variable than raw resolution and adds meaningful entropy. The combination of resolution, available area, colour depth, and pixel ratio is one of the oldest and still one of the more identifying hardware signals.

CPU cores: navigator.hardwareConcurrency

navigator.hardwareConcurrency returns the number of logical processors available to the browser, the figure a site would use to decide how many web workers to spawn. In practice it clusters into a handful of common values, 4, 8, 12, and 16 being typical, so on its own it provides only a couple of bits of entropy. It still narrows the field: a device reporting 24 logical cores is in a much smaller population than one reporting 8. Some browsers cap or quantise this value (Safari, for instance, reports a limited maximum) precisely to flatten the distribution and reduce its usefulness.

Device memory: navigator.deviceMemory

navigator.deviceMemory reports approximate device RAM in gigabytes, but deliberately coarsely. The specification restricts it to a small set of rounded values, 0.25, 0.5, 1, 2, 4, and 8, and caps the maximum at 8 even on machines with 32 or 64 GB. This rounding was a privacy decision: it gives sites a rough capability hint while keeping the entropy to roughly two bits. It is supported in Chromium-based browsers and absent in Firefox and Safari, so its mere presence or absence is itself a small signal about which engine you run.

GPU model: the WebGL renderer string

The graphics layer is the richest hardware signal of the group. Through WebGL, a page can query the renderer and vendor strings, historically via the WEBGL_debug_renderer_info extension, which return text such as ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 Direct3D11 vs_5_0 ps_5_0) or a specific Apple or Adreno or Mali identifier. This string often names the exact GPU model and the graphics driver path, which is highly specific, frequently contributing several bits and sometimes nearly identifying a device when paired with screen geometry.

Browser vendors recognised this and have clamped down. Recent versions of Chrome and Firefox now return a generalised renderer string for ordinary pages, reporting a vendor-level descriptor instead of the precise model, so the exact card is no longer trivially readable. Tor Browser and similar hardened browsers go further and block or standardise the debug renderer entirely. Note that this is distinct from WebGL rendering fingerprinting, where subtle differences in how a scene is drawn produce a hash; here we are concerned only with the descriptive model string the GPU reports about itself.

Input and device-count signals

Several smaller hardware traits round out the profile:

  • Pointer and touch capability. CSS media features such as pointer: coarse versus pointer: fine, the hover capability, and navigator.maxTouchPoints reveal whether you use a mouse, a touchscreen, or both. maxTouchPoints often reports a specific maximum (such as 5 or 10) that distinguishes device classes.
  • Media device counts. navigator.mediaDevices.enumerateDevices() can be called without permission to count how many cameras, microphones, and speakers are attached, even though their labels are hidden until you grant access. The counts alone, two microphones and one camera versus none, separate device types and configurations.

Mobile versus desktop

The hardware story differs sharply between form factors. Desktops and laptops vary enormously in resolution, core count, and GPU, so the combination tends to be highly distinguishing. Phones are more uniform: a given popular handset model ships millions of identical units with the same screen, the same chip core count, the same GPU, and the same pixel ratio. That uniformity means a single phone model blends into a large crowd on hardware alone. The trade-off is that the hardware profile pins down your exact device model with high confidence, which combined with other signals can still isolate you. In short, desktops leak more variety, while mobiles leak more certainty about which device you hold.

Defences that actually move the needle

Because hardware signals are read silently and cannot be reset, the defences are mostly about browser design choices rather than user toggles.

  • Use a browser that caps and standardises these values. Engines that quantise core count, round device memory, and generalise the GPU string shrink the entropy of each field. Safari's conservative reporting and the recent WebGL renderer generalisation in Chrome and Firefox are concrete examples. Hardened browsers go furthest by returning fixed or standardised values shared across their whole user base.
  • Maximise the browser window. Viewport dimensions (innerWidth and innerHeight) are part of the fingerprint, and an oddly sized window is a rare value. Running maximised, so your viewport matches a common resolution, places you in a larger crowd than a uniquely sized window does. This is a small but genuine, no-cost improvement.
  • Understand Tor's letterboxing. Tor Browser does not report your true window size. Instead it pads the rendered content with grey margins so the reported viewport snaps to one of a small set of standard dimensions (stepped in increments such as 200 by 100 pixels). Every Tor user therefore reports one of a few common sizes regardless of their actual monitor, which is why resizing the window in Tor shows visible bars. This standardisation is the most effective answer to screen-geometry fingerprinting available.
  • Be realistic about spoofing. As with other layers, faking a single hardware value usually backfires. Reporting an impossible combination, a touch-only pointer with a 49-inch desktop resolution and 32 reported cores, produces a profile no real device matches, making you more distinctive rather than less. Coherence beats fabrication.

Putting it together

Screen geometry, core count, device memory, GPU model, and input capabilities are each modest on their own, but they share three dangerous properties: they are read without consent, they are remarkably stable over time, and they are largely independent of one another, so their entropy adds up. Together they form a durable hardware identifier that outlives cookie clearing and survives a clean reinstall.

The practical defence is not to hunt for a spoofing trick but to choose a browser that deliberately flattens these values, to run maximised so your dimensions look ordinary, and to understand that letterboxing and value-capping are doing real work behind the scenes. Running the privacyscore.dev test will show you which of your hardware traits stand out most, and that visibility is the first step toward blending into a larger crowd rather than carrying a unique device signature wherever you browse.