css media query fingerprinting

CSS fingerprinting: what media queries reveal

CSS fingerprinting identifies a machine using only stylesheet media queries and system colours, with no JavaScript at all. Media queries reveal the pointer type, the operating-system dark-mode setting, display resolution and colour gamut, the screen size, and accessibility preferences; CSS system colours reveal the operating system itself. Each is read by loading a different resource per branch, so the server learns the answer from which request arrives.

Almost everything written about what a browser fingerprint is assumes JavaScript. Disable it, block it, patch it, and the discussion is about what a script can read.

CSS does not need a script. A stylesheet can ask what kind of pointer you have, whether your system is in dark mode, how many colours your display shows, and how large it is, and it can report the answer by loading a different background image per branch. No JavaScript runs, so no page-level stealth layer is involved at all.

This page covers what the features expose, the two places where CSS and JavaScript can disagree about the same machine, the system-colour surface almost nobody knows about, and what a consistent answer looks like.

How a stylesheet exfiltrates without a script

A stylesheet exfiltrates data with no JavaScript at all by loading a different image per media-query branch, so the browser that requests one image rather than another has answered the query. The pattern is a few lines of CSS and has been known for years:

@media (pointer: fine)   { body { background-image: url("/p?fine"); } }
@media (pointer: coarse) { body { background-image: url("/p?coarse"); } }
@media (prefers-color-scheme: dark) { body { border-image: url("/c?dark"); } }

Only the matching branch loads its image, so the server learns the answer from which request arrives. Repeat across a dozen features and you have a fingerprint assembled entirely from network requests.

Two consequences worth being explicit about:

• Blocking or patching JavaScript does nothing here. There is no function to override and no object to inspect.
• It works on the first paint, before any script you inject has a chance to run, which sidesteps the timing problem that page-level patches have anyway.

Estimates of how much entropy this reaches vary, and the useful number is not the total. It is that these values are free to collect and are rarely part of anyone's checklist.

The media features that actually carry information

Not every media feature carries useful entropy. The ones that identify a machine fall into five groups: pointer and hover capabilities, colour scheme, display characteristics, accessibility preferences, and size.

Media feature	What it reveals
pointer, any-pointer, hover, any-hover	Input devices: mouse vs touch, and whether the device has both
prefers-color-scheme	OS dark-mode setting, close to a coin flip across real users
resolution, color-gamut	Display panel class (p3 marks a modern, wide-gamut display)
prefers-reduced-motion, prefers-contrast, forced-colors, inverted-colors	Accessibility preferences; a non-default value is rare and identifying
width, height, device-width, device-height	Screen and viewport size, and the CSS/JavaScript consistency trap below

Pointer and hover. pointer, any-pointer, hover, any-hover. A desktop with a mouse reports fine and hover. A phone reports coarse and none. A touchscreen laptop reports both, through the any- variants, which is how a device with two input methods is distinguished from one with a single method.

Colour scheme. prefers-color-scheme is the operating system's dark mode setting, and it is close to a coin flip across real users, so it is a genuine bit rather than a constant.

Display characteristics. resolution and color-gamut describe the panel. color-gamut: p3 says a modern, better-than-average display; see color-gamut as a display fingerprint for how that one media query alone narrows the field.

Accessibility preferences. prefers-reduced-motion, prefers-contrast, forced-colors, inverted-colors. Almost everyone leaves these at the default, which is exactly why a non-default value is informative: it is rare.

Size. width, height, device-width, device-height, and the interaction with resolution. Which brings us to the trap.

Trap one: CSS and JavaScript can disagree about the screen

In Firefox, the size a media query resolves against and the size screen.width reports come from different code inside the browser - two separate paths to the same physical fact. Patch only the JavaScript side and the two disagree about the same machine; this is a mistake specific to spoofing, and it is invisible unless you look for it directly.

Concretely, spoofing only the JavaScript side produces a browser where:

screen.width                                  // 1920
matchMedia('(device-width: 1920px)').matches  // false, the real panel is something else

One line of CSS and one line of JavaScript, and they disagree about the machine they are running on. That is not an unusual value, it is a contradiction, and contradictions are what the checks in this whole subject are built on.

The same applies to the pointer capabilities: a touchscreen laptop reporting coarse to CSS while the JavaScript side claims a desktop persona is the same class of mismatch.

This project handles both in the browser's own media-feature code, so the CSS device size comes from the same profile as screen, and the pointer capabilities report a mouse rather than whatever hardware the host happens to have.

How to check it yourself

console.log(screen.width, screen.height);
console.log(matchMedia(`(device-width: ${screen.width}px)`).matches);   // want true
console.log(matchMedia('(pointer: fine)').matches,
            matchMedia('(any-pointer: coarse)').matches);

If the second line is false, something is spoofing one side only.

Trap two: CSS system colours give away the operating system

CSS system colour keywords - ButtonFace, ButtonText, Canvas, CanvasText, Highlight, HighlightText, Menu, Field, and a few dozen more - resolve to the operating system's own interface palette, readable with no permission and one function call. This surface is genuinely obscure, and it is checked in production:

const d = document.createElement('div');
d.style.color = 'ButtonText';
d.style.backgroundColor = 'ButtonFace';
document.body.appendChild(d);
getComputedStyle(d).color;            // an RGB triple from the OS theme

Those values are the actual theme colours. On Windows they come from the Win32 palette. On Linux they resolve through the desktop theme, and the RGB values are different, even when the user agent says Windows.

So a browser claiming Windows and returning a Linux theme's palette has answered the platform question twice with two different answers, from a surface most people have never enumerated. A commercial fingerprinting service hashes exactly this set.

This project pins the full palette to the Windows default so it matches the claimed platform, with one exception worth knowing: when the persona is a dark-theme user, the palette is skipped and the dark-mode preference is set instead, because pinning a light palette onto a dark-mode profile would create the contradiction it exists to prevent.

What a consistent CSS answer looks like

Working from all of the above:

• Pointer and hover describe one plausible input device, and agree between the any- variants and the plain ones.
• The CSS device size matches screen, exactly.
• prefers-color-scheme matches the system-colour palette. Dark mode with a light palette is a contradiction.
• Accessibility preferences are at their defaults unless you have a reason, because non-default values are rare and therefore identifying.
• color-gamut and resolution suit the display you claim.
• Everything is stable for the session. A colour scheme that flips mid-session is a browser nobody has.

Conclusion

CSS fingerprinting matters not because it is the strongest signal but because it is the one that operates below every layer people normally work at. There is no script to patch, so the values have to be right at the source or not at all.

The two traps are the practical takeaway. CSS and JavaScript reach the screen size by different routes inside the browser, and the system-colour palette is a platform tell sitting in plain sight, readable with one getComputedStyle call.

Short answers to the questions that lead here

Can a website fingerprint me with CSS alone? Yes. Media queries can load different resources per branch, so the server learns the answer without any script running.

Does blocking JavaScript stop CSS fingerprinting? No. That is the point of it.

What is prefers-color-scheme worth to a tracker? Roughly one bit, and a reliable one, because real users are split between the two settings.

Why would CSS and screen.width disagree? Because the browser resolves them through different code, so spoofing one and not the other leaves them inconsistent.

Are CSS system colours really used for fingerprinting? Yes, by hashing the resolved values of the system keywords. They also reveal the operating system independently of the user agent.

Should I set unusual accessibility preferences? No. Almost everyone is at the default, so anything else narrows you down rather than hiding you.

See also: screen size and viewport tells, which is the JavaScript half of the size question, why headless browsers render different fonts, another platform tell that no script controls, and the checklist for being detected on one site.

Sources

• MDN's reference for the @media at-rule and the individual media features named above.
• Published work on CSS-based fingerprinting, which is where the load-an-image-per-branch technique is described.
• This project's own media-feature and system-colour handling, and the reason the palette is skipped for dark-theme personas.

---

From the notes of invisible_playwright, a Firefox patched at the C++ level. The system-colour palette is pinned here because a commercial detector was hashing it and catching the host operating system through it.