Screen and Viewport Fingerprinting Explained

Your browser hands over the exact pixel dimensions of your display before you click anything. Not roughly, not rounded off. The full width and height of the screen, the working area left after your taskbar, the size of the window you happen to have open, and how much of that window is actually showing the page. No permission prompt, no visible sign it happened.

It sounds harmless. It isn’t, and it still catches setups that got everything else right.

I run real proxy and cloud phone farms, and the hardware and environment layer is where I spend most of my time. This piece is deliberately defensive and third person: how the technique works and how it gets defended against, not a recipe for beating any particular site. There are no undetectable promises here either. Understanding this signal removes one more contradiction from a setup. It does not make anything invisible.

What a page can actually read

When a script runs, it can ask the browser a short list of questions about your display, and the browser answers all of them without asking you:

• Screen width and height — the full panel dimensions.
• Available width and height — the screen minus whatever the operating system reserves for a taskbar or a dock.
• Colour depth — how many bits describe each pixel.
• Device pixel ratio — whether you’re on a standard display or a high density one.
• Window size — the whole browser, frame and all.
• Viewport size — the part actually showing the page, after the toolbar and any scrollbar.

That last pair is worth separating clearly, because the gap between the window and the viewport describes your browser setup in a surprisingly specific way.

Why any of this identifies anybody

On its own, a screen that is 1920 by 1080 is the most common resolution in the world. It tells a site almost nothing.

But fingerprinting has never been about one value. It’s about the combination, and about whether that combination is internally consistent. Take that same common resolution and add an available height implying no taskbar at all, a pixel ratio that doesn’t match any real display of that size, a window larger than the screen it supposedly sits on, and a viewport height that’s a perfectly round number. Individually, every one of those is plausible. Together they describe a machine that does not exist.

That’s the whole idea, and it’s worth saying plainly: detection is rarely looking for a forbidden value. It’s looking for a set of values that cannot all be true at once.

The contradictions that come up most

The window bigger than the screen. Almost comically common in automated setups. A script sets a window size for consistency and sets it larger than the reported screen. No human has ever had a browser window wider than their monitor. That’s not suspicious, it’s impossible, and it’s trivial to check.

Available space that never changes. On a real desktop, available height is screen height minus what the operating system reserves, and that subtraction is specific and fairly predictable per platform. When available dimensions come back exactly equal to the full screen, that describes a machine with no system interface at all, which in practice means a headless environment or a spoof that only changed the top level numbers.

Pixel ratio mismatch. A high density display reports a ratio above one, and that ratio has consequences elsewhere: it changes how certain measurements are reported and which image assets get requested. Claiming a high density ratio while every other measurement only makes sense on a standard display describes two different machines at once.

The mobile that isn’t a mobile. A profile claims to be a phone through the user agent, then reports a screen far too wide, a viewport with a desktop shape, a pixel ratio no phone has, and an orientation that never changes. The user agent is the easiest thing in the world to change, so when it disagrees with the measurements, detection trusts the measurements.

The round number problem. Real viewport heights are messy. They’re whatever is left after a specific browser version’s toolbar, on a specific operating system, at a specific zoom level, with or without a bookmarks bar. That leftover is almost never clean. When a large population of sessions all report suspiciously tidy dimensions, or one set appears far more often than any real hardware distribution would produce, the cluster becomes its own signal.

Multiple monitors. A real desktop user with two displays produces readings that look odd until you know why: a window positioned far beyond the width of the primary screen, available area reflecting one display while the window sits on another. Those look inconsistent at a glance and are completely genuine, and a decent detection system knows the shape of that pattern. The interesting failure is the reverse. A spoofed profile almost never reproduces it, so a population of sessions that all sit perfectly inside a single display, always at a tidy position, is quietly unusual in a way real hardware is not.

Orientation. A genuine phone rotates. Width and height swap, the viewport reflows, the orientation value changes, and all of it happens together because it’s one physical event. A profile claiming to be a phone that has never once rotated, frozen in portrait forever, is describing a device nobody is holding.

The part people underestimate

A site doesn’t only compare your values against physics. It compares them against every other session it has seen.

If a particular combination of screen, viewport and pixel ratio appears across hundreds of accounts that otherwise claim to be unrelated strangers, the combination itself becomes the link. No single value was wrong. The sharing was.

How it gets defended, and where defences fall short

The good tools don’t try to invent a display. They take a real, coherent hardware profile and keep every dependent value consistent with it. Screen, available space, pixel ratio, window, viewport and reported measurements all come from one plausible machine, and they stay that way for the life of the profile. That consistency is the entire job.

The weaker approach is to randomise. A tool picks a fresh screen size each session, or adds a small random offset to make the value unique. That feels like privacy and it’s usually the opposite. A display that changes every session describes someone who buys a new monitor every morning. A value randomised into a range nobody actually owns is more identifying than the common value it replaced, because now you’re the only session in the world reporting it. This is the trap for anyone thinking of fingerprinting as hiding rather than as blending.

There’s also a category of leak that top level spoofing doesn’t reach. Layout is measured, not just declared. A page can render an element, measure what it got back, and infer the real available space from the result. It can watch how text wraps. It can check what a media query resolves to. If the top level numbers were rewritten but the rendering underneath still reflects the true window, those two disagree, and the disagreement is the finding.

That’s the same lesson as canvas and webgl: the values a page derives from doing real work are much harder to fake than the values it simply asks for.

Zoom deserves a brief mention for the same reason. Changing the zoom level shifts several of these measurements at once, in a specific and related way. A setup that alters one without the others produces a relationship no zoom level would ever create.

Practical, defensive takeaways

Stop thinking about any single number and start asking whether the whole picture describes one real machine.

• Pick a hardware profile that genuinely exists and is genuinely common.
• Let the browser report the values that follow from it, rather than overriding them piecemeal.
• Keep it stable across sessions, because stability is what a real person looks like.
• Check the derived values, not just the declared ones, because that’s where contradictions show up.

The other useful habit is to actually look. These values are readable in about a minute in any browser console, and comparing what a profile claims against what the layout genuinely produces tells you more than any vendor page will. If a tool claims to handle this layer, that claim is testable. Test it rather than taking it on trust.

The short version

Screen and viewport fingerprinting is old, quiet and still effective, because it was never really about your resolution. It’s about whether your resolution, available space, pixel ratio, window, viewport and rendered layout all agree they belong to the same machine.

Tools that keep one coherent profile handle it well. Tools that randomise per session usually make it worse. And the leaks that survive are almost always the values a page measures rather than the values it asks for.

I test these browsers on real multi account setups, and the written reviews and picks I actually trust are all here. Nothing there promises anything is undetectable, because nothing is. What the reviews do is show what each tool actually reports, and where it actually leaks.

Get new guides and videos first — join the Telegram channel.