What changes in a fingerprint when you resize the window
The short answer
Dragging a browser window bigger or smaller changes a handful of live JavaScript values (innerWidth, innerHeight, outerWidth, outerHeight, and whatever matchMedia breakpoints depend on them). It does not change your screen resolution, your device pixel ratio, or your canvas and WebGL renders. The problem isn’t that resizing creates a new fingerprint out of thin air. It’s that resizing can knock the window measurements out of sync with whatever screen and viewport values an anti-detect profile already told the page. That mismatch, not the resize itself, is what a fraud script can flag.
What actually moves when you drag the window border
Four values change the instant you resize:
window.innerWidth/window.innerHeight: the viewport, meaning the content area inside the browser chrome.window.outerWidth/window.outerHeight: the full browser window including toolbars, tabs, and borders.document.documentElement.clientWidth/clientHeight: usually tracks innerWidth minus the scrollbar.- Whatever CSS
matchMediaqueries key off viewport width, which can change layout, font wrapping, and how manygetClientRectsa block of text produces.
What doesn’t move: screen.width, screen.height, screen.availWidth, screen.availHeight, and window.devicePixelRatio. Those describe the physical monitor and the OS-reported usable area, not the browser window. A monitor doesn’t get smaller because you shrank Chrome. devicePixelRatio only changes with actual zoom level or a genuine DPI change, not a window drag.
This split is the whole story. Fingerprinting scripts read both sets of values and check whether they make sense together.
The mismatch that resizing creates
A real, unmodified browser can’t have a window bigger than the screen it’s rendered on (barring multi-monitor spanning, which has its own signature). So a script can sanity-check outerWidth <= screen.width and outerHeight <= screen.availHeight. It can also compare outerWidth - innerWidth against a plausible chrome/border width for the claimed OS and browser version. Windows Chrome, macOS Safari, and Linux Firefox all have slightly different typical border and toolbar heights, and a script that’s seen millions of sessions has a rough distribution for what’s normal.
Here’s where anti-detect profiles get exposed. Tools like Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty inject a spoofed screen resolution and open the browser window at a size that matches it, so on launch everything lines up. If you then manually drag that window smaller or bigger mid-session, the browser’s real, unspoofed outerWidth/outerHeight change to reflect what you actually did, while the spoofed screen.width/screen.height stay fixed because those are set once at profile creation and don’t track your window manipulation. Now the two numbers that should move together in a real browser have drifted apart in a way a scripted check can notice. It’s not proof of anything on its own, but it’s one more inconsistency added to a pile that a detection system is already scoring.
The same logic applies to maximized state. A lot of scripts treat outerWidth == screen.availWidth (or close to it) as evidence the window is maximized, which is the overwhelmingly common state for real users on Windows. A profile that launches un-maximized at an odd fractional size, especially one that doesn’t match any common laptop or monitor resolution, stands out statistically even before you touch the resize handle.
How canvas and WebGL fit into this, or don’t
It’s worth being precise here because people conflate these. Canvas and WebGL fingerprints are rendered into an offscreen <canvas> element at fixed pixel dimensions set by the script itself, not by your window size. Resizing the browser window doesn’t touch how your GPU rasterizes a triangle or renders a text string into that canvas. Those fingerprints stay the same whether your window is 800px wide or 1600px wide. If you see a canvas hash change after a resize, that’s coming from something else in the profile changing, not the resize.
What can shift is layout-dependent entropy: if a script measures how a paragraph of text wraps, or counts getClientRects for a span at the current viewport width, that count changes with window width. It’s a much weaker signal than canvas or audio fingerprinting and most serious fingerprinting libraries know it’s unstable, which is exactly why libraries like FingerprintJS intentionally down-weight or exclude raw viewport size from their stable identifier. A user resizing their own browser between sessions is normal behavior, and a fingerprinting vendor that penalized it would generate constant false positives. Cruder, custom-built fraud engines built in-house by a specific platform don’t always make that distinction, though, and some do fold window dimensions into a broader device score alongside IP, timing, and behavioral signals.
Why headless and automated browsers give themselves away here
This is where window size becomes a real tell rather than a theoretical one. Headless Chrome launched through Puppeteer or Playwright without explicit viewport configuration defaults to a fixed size, historically 800x600, and even when scripts set a custom size it’s often an exact round number like 1920x1080 with the window positioned at (0,0). Real human sessions cluster around common laptop and monitor resolutions but with far more variance in window position, in whether the browser is maximized, and in outerWidth minus innerWidth deltas that match a genuine browser chrome height. A fleet of automated sessions that never fire a resize event, or that all report identical outerWidth-to-innerWidth deltas across supposedly different machines, is a pattern a detection system can cluster on across accounts even without pinning any single session.
What this means for profiles in Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty
None of these tools claim their profiles are undetectable, and none of them should be treated that way. What they do is generate an internally consistent set of screen, viewport, and hardware values at profile creation and hold that profile across a session so the numbers agree with each other. Where I’ve seen operators shoot themselves in the foot is manual habit: dragging the browser window around to fit their monitor layout, snapping it to half-screen, or resizing it to stack multiple profiles side by side for review, without realizing that action changes real API values that no longer agree with the profile’s stored screen resolution.
The tools themselves don’t stop you from doing this because they can’t intercept every window manager event at the OS level the same way they can intercept a JS API call from inside the page. It’s a gap in enforcement, not a flaw unique to any one of these five products, and it applies about equally across them.
The practical rule I follow
Set the window size once, at launch, to whatever the profile’s screen resolution supports, and leave it alone for the session. If you need multiple profiles visible at once, use a virtual desktop or a second monitor instead of manually shrinking each window, since resizing after launch is the exact action that pulls outerWidth/outerHeight away from the values the profile already committed to. It’s a small habit, and it won’t make an account unbannable or a browser undetectable on its own, but it removes one more inconsistency from a pile a fraud script is already scoring.
Want the rest of the pile? Check the other posts on Anti-Detect Review for how canvas, WebGL, audio, and timezone signals get checked against each other, and which of these tools hold up under that scrutiny in hands-on testing.
Get new guides and videos first — join the Telegram channel.