← All articles

Headless vs Headful: What Detectors See

2026-08-13 · 6 min read

Headless browsers leak signals that a windowed browser cannot produce, and modern headless modes have closed most but not all of the gap. The remaining differences cluster in three places: window and screen metrics that describe no physical display, rendering paths that behave differently without a compositor, and automation flags exposed by the driver.

Why is headless detectable at all?

A headless browser renders without a window manager, a real display or a mouse. Everything downstream of those absences behaves slightly differently: reported outer window dimensions, whether a screen refresh rate exists, how fonts are rasterised, and whether user input events have plausible timing. Each difference is small; together they form a recognisable profile.

Newer headless modes run the full browser engine and removed the most obvious tells, which is why guidance written before those changes overstates how visible headless is today. It is no longer trivially detectable, and it is not equivalent to headful either.

Which signals still differ?

The reliable differences are structural rather than flag-based, which means they survive attempts to patch individual properties. Window geometry is the clearest: a browser with no window still has to answer questions about its window.

Signal	Headful	Headless
Outer window vs viewport	Differs by browser chrome	Often identical
Screen available area	Excludes taskbar or dock	Equals full screen
Window position	Arbitrary	Often 0,0
Mouse movement before click	Present	Usually absent
Focus and blur events	Occur naturally	Rarely occur
Automation flag	Absent	Present unless patched

Which matters more, the flags or the behaviour?

Behaviour, by a wide margin, because flags are the part everyone patches. Any stealth library removes the obvious automation property within days of it being documented. What survives is the absence of human interaction: pages that receive a click with no preceding mouse movement, forms filled at constant intervals, and sessions that never lose focus.

These are observable from ordinary page scripts and require no privileged access to detect, which is why they remain effective long after the flag-based checks stop working.

When is headless the right choice?

Headless is well suited to work where nobody is logged in and volume matters: checking whether pages render, sampling public prices, monitoring availability. It is poorly suited to anything behind a login on a platform with an active risk system, where the cost of one flagged session exceeds the resource saving.

Task	Better mode	Why
Public page monitoring	Headless	No account at risk
Rendering and layout tests	Headless	Speed and parallelism
Logged-in account work	Headful	Account value exceeds savings
Anything behind a bot manager	Headful	Behaviour signals dominate

Why does headless still leak after the flags are patched?

Because the environment differs beyond the flags. A headless browser has no real window manager, no display server and no physical input device, so window dimensions, device pixel ratio, media capabilities and permission behaviour all differ from a desktop session in ways no single setting covers.

Newer headless modes close most of that gap by running the real browser pipeline with the window hidden, which is why 2 headless setups can score completely differently. Check which mode a tool actually uses rather than trusting the word itself — the 2 approaches share a name and very little else.

What if you need scale and safety together?

Run headful on a machine with a virtual display rather than choosing between them. That combination keeps the window manager, the compositor and the real rendering path while still running on a server without a monitor attached, which removes the structural differences without giving up automation.

Then spend the remaining effort on interaction rather than on flags. Moving the cursor before clicking, varying delays, and letting pages sit idle occasionally costs very little throughput and addresses the signals that patching cannot reach. For account work the answer is usually simple: run headful. The resource cost is real but bounded, and 10 headful profiles on 1 machine are cheaper than 1 suspended account caused by saving memory.