Choosing a screen resolution that does not stand out

Screen resolution feels like a throwaway detail compared to canvas hashes or WebGL renderer strings, but it’s one of the first values a fingerprinting script reads, and it’s one of the easiest to get wrong when you’re setting up a browser profile. I run proxy infrastructure and cloud phones for a living, and I test anti-detect browsers against real detection scripts as part of that work. Resolution mismatches are one of the most common, most avoidable tells I see in profiles that otherwise look fine.

What a resolution fingerprint actually contains

When a page runs window.screen.width and window.screen.height, it’s reading the full display resolution reported by the OS, not the size of the browser window. Alongside that, scripts typically pull screen.availWidth and availHeight (the usable area after taskbars and docks), window.innerWidth and innerHeight (the actual viewport the page renders into), devicePixelRatio (how many physical pixels map to one CSS pixel), and screen.colorDepth or pixelDepth. Multi-monitor setups can also expose screen.availLeft and availTop, and newer APIs like window.screen.isExtended flag whether more than one display is attached at all.

None of these values are secret and none of them require permission to read. That’s what makes resolution such a cheap, high-value signal for a detection script: it’s available on page load with zero user interaction, and it correlates with a lot of other things a script can check, like GPU renderer strings, font rendering, and touch support.

Why “just use 1920x1080” is a start, not a solution

The instinct is to pick the most common desktop resolution and move on. That’s not wrong, but it’s incomplete. 1920x1080 is common because it’s the default panel size on a huge share of consumer monitors and laptops. If your profile reports 1920x1080 but every other signal points to a different kind of machine, the resolution itself stops helping.

A few examples of the mismatches that actually happen:

devicePixelRatio that doesn’t match the claimed hardware. A 1920x1080 resolution with a devicePixelRatio of 2 is unusual on Windows but normal on some MacBook configurations running scaled. If the rest of the profile (user agent, WebGL vendor string, font list) says Windows desktop, a Mac-typical pixel ratio is a contradiction a script can flag without needing anything exotic.

availHeight that’s identical to height. Real desktop OSes reserve space for a taskbar or dock, so availHeight is almost always a little less than height, not equal to it. A profile where the two values match exactly is a small but real signal that the “display” is synthetic rather than a physical monitor with a real shell around it.

Viewport size that never changes. On a real device, innerWidth and innerHeight shift slightly between sessions as windows get resized, browser chrome changes, or a user switches from maximized to windowed. A profile that reports the exact same viewport pixel-for-pixel across dozens of sessions looks more like a fixed automation container than a person browsing.

Resolution values with round numbers that don’t correspond to a real panel. Somewhat obvious ones aside, there are resolution values that show up constantly in automation defaults and almost never in retail hardware. If a script has a list of known headless or automation defaults, reporting one of them is worse than reporting nothing consistent at all.

Multi-monitor leakage. If availLeft or availTop are non-zero, or isExtended reports true, that tells a script the session is running with multiple displays. That’s not damning on its own, plenty of real users run dual monitors, but it’s another data point that has to line up with the rest of the story your profile is telling.

How anti-detect browsers handle this

Tools like Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty all let you set a screen resolution per profile, usually from a preset list or a custom value. Where they differ is in how deep the spoofing goes. Some tools only override screen.width and screen.height at the JavaScript layer while leaving devicePixelRatio or availHeight untouched, which reintroduces the exact mismatches described above. Others compute a coherent set of values together, deriving pixel ratio, available area, and viewport bounds from the same underlying profile so they don’t contradict each other.

I’m not going to hand out a verdict on which vendor does this correctly across the board, because that depends on the specific build, the specific profile template, and how the detection script you’re worried about is written, and I haven’t run every combination against every target. What I can say from testing is that the gap between “sets screen.width” and “sets a coherent resolution profile” is real, and it shows up the moment you open dev tools and manually check screen, visualViewport, and devicePixelRatio side by side inside the spoofed browser. That’s a five-minute check anyone can do before trusting a profile with real work.

None of this makes a profile undetectable. Resolution is one signal among dozens a sophisticated script can combine, and a platform doesn’t need certainty from resolution alone to flag an account, it just needs enough correlated anomalies to raise a score. Treat resolution consistency as reducing one source of noise, not as a shield.

A practical way to pick a resolution

Instead of asking “what resolution hides me,” ask “what resolution is boring for the device I’m claiming to be.” A few things that hold up under that framing:

Match the resolution to the platform and region you’re operating in. If a profile claims to be a specific OS and locale, the resolution distribution for that combination in the real world isn’t random, certain panel sizes dominate certain markets and device classes. Wildly uncommon combinations stand out precisely because they’re uncommon, not because anything is technically wrong with them.

Keep devicePixelRatio, availHeight, and viewport size internally consistent with each other and with the claimed OS. This matters more than which specific resolution you pick. A common resolution with an inconsistent pixel ratio is worse than a slightly less common resolution where every value agrees.

Avoid exact round numbers that never occur on real hardware, and avoid values that are identical across every profile in a batch. If you’re running many profiles, some natural variance across a small set of common, legitimate resolutions looks more like a population of real users than one resolution copy-pasted everywhere.

Check what the browser actually reports, not what the settings panel says you configured. Anti-detect tools sometimes apply an override at one layer and miss a related API. Open the profile, run screen.width, screen.availHeight, window.devicePixelRatio, and window.visualViewport.width in the console, and confirm they tell a coherent story before you rely on it.

Resolution is a small piece of a much larger fingerprint puzzle that includes canvas rendering, audio context output, font enumeration, WebGL parameters, and timing behavior. Getting it right doesn’t make an account safe or a browser unbannable. It just removes one of the cheaper, more mechanical ways a script can catch an inconsistency, which is worth doing carefully rather than treating as a checkbox.

If you want more breakdowns like this on how specific fingerprint signals actually work and how different anti-detect browsers handle them in practice, check out the rest of the site at Anti-Detect Review.

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