Headless vs Headful Browsers: When to Use Each Mode

What the Difference Actually Is

The terms "headless" and "headful" (also called "headed") describe whether the browser renders its output to a visible window. Under the hood, the same browser engine powers both modes. Chrome headless and Chrome headed use identical versions of the Blink rendering engine, V8 JavaScript engine, and network stack. The page goes through the same loading, parsing, scripting, and layout phases in both cases.

The practical difference is in the final rendering step. A headed browser takes the computed layout and paints it to a window on your screen. A headless browser skips this compositing and painting step entirely unless you explicitly request a screenshot or PDF. Layout still happens because JavaScript code can query element dimensions and positions, but the expensive pixel-painting work is eliminated.

Since Chrome 112's "new headless" mode, the behavioral gap between headless and headed has narrowed to almost nothing. Older headless implementations (Chrome's original headless mode, released in Chrome 59) were actually a separate browser implementation that shared some code but not all behavior with the full Chrome browser. The current implementation uses the exact same code path for both modes, switching only the display backend. This means pages render identically, JavaScript executes the same way, and Web API behavior matches between modes.

Performance Differences

Headless mode is measurably faster than headed mode in most automation scenarios. The performance gain comes from three sources: eliminating the compositing and painting steps, reducing GPU utilization, and avoiding window management overhead from the operating system.

In practice, the speed difference varies by workload. For simple page loads and data extraction, headless mode runs 10-30% faster because each page spends less time in the rendering pipeline. For test suites that execute hundreds of page transitions, the cumulative time savings are significant. A test suite that takes 10 minutes in headed mode might complete in 7-8 minutes headless. For tasks that are bottlenecked by network latency (like waiting for slow API responses), the rendering speed difference is negligible because the browser spends most of its time waiting for data regardless of mode.

Memory usage is also lower in headless mode, though not dramatically so. The browser engine itself uses the same amount of memory for DOM structures, JavaScript heaps, and network buffers. The savings come from not allocating GPU-backed textures and compositor layers. A typical page might use 150-250 MB in headed mode and 100-200 MB in headless mode, depending on visual complexity.

Startup time differs more noticeably. A headless browser can launch without initializing the display subsystem, window manager integration, or GPU context. On a CI server with no GPU, this avoids the fallback to software rendering that can add seconds to headed browser startup. In Docker containers, headless mode eliminates the need for a virtual framebuffer (Xvfb), simplifying the container configuration and reducing image size.

Debugging and Development Workflows

Headed mode is vastly superior for developing and debugging automation scripts. When you can see the browser window, you can watch your script execute step by step, observe which elements are being clicked, see how the page responds, and immediately notice when something goes wrong. This visual feedback loop makes headed mode essential during the script development phase.

Most automation frameworks make switching between modes trivial. In Playwright, change browser = p.chromium.launch() to browser = p.chromium.launch(headless=False). In Puppeteer, pass { headless: false }. In Selenium, remove the --headless=new argument from ChromeOptions. The common workflow is to develop in headed mode, verify everything works visually, then switch to headless for production execution.

Playwright enhances this workflow with several debugging tools that bridge the gap. The page.pause() method opens the Playwright Inspector, an interactive debugger that lets you step through actions, inspect elements, and generate selectors in real time. The --headed flag in Playwright Test runs tests visually. Trace files capture a complete record of browser activity (screenshots, DOM snapshots, network requests, console logs) that you can review in the Trace Viewer after a headless test run, giving you visual debugging without requiring headed mode at runtime.

Selenium's debugging options include taking screenshots at specific points in the script, logging browser console messages, and using the --remote-debugging-port flag to connect Chrome DevTools to the running browser instance (even in headless mode) for live inspection of the DOM, network traffic, and JavaScript execution.

Anti-Bot Detection Considerations

Some anti-bot systems specifically target headless browsers. While the behavioral gap between headless and headed Chrome has largely closed, detection methods still exist. The navigator.webdriver property is set to true in automated browsers (both headless and headed modes), but some systems check for rendering artifacts, GPU information strings, or browser plugin arrays that can differ between modes.

Running in headed mode does not automatically bypass detection, but it eliminates one category of detection signals. More importantly, headed mode allows you to see exactly what the anti-bot system is doing: you can observe CAPTCHA challenges, JavaScript-based device verification screens, and blocking responses in real time, which helps you develop appropriate countermeasures.

For production scraping against sites with active anti-bot measures, the choice between headless and headed depends on the specific detection methods deployed. Some teams run headed browsers on virtual display servers (using Xvfb or a similar virtual framebuffer) to get the rendering characteristics of headed mode without needing a physical monitor. Others use stealth plugins that patch the JavaScript API differences between headless and headed modes, effectively making headless Chrome indistinguishable from headed Chrome at the detection layer.

Visual and Accessibility Testing

Visual regression testing, where you compare screenshots of a page before and after a code change to detect unintended visual differences, works in both modes but can produce subtly different results. Headed mode screenshots include the effects of GPU-accelerated rendering, system-level font hinting, and subpixel antialiasing that match what real users see on their screens. Headless mode screenshots may differ slightly in font rendering or subpixel behavior, depending on the system's font configuration, installed fonts, and GPU driver availability.

For pixel-perfect visual testing, consistency matters more than which mode you choose. Running all comparisons in the same mode (whether headless or headed) produces reliable diffs. Problems arise when baseline screenshots are captured in one mode and comparison screenshots in another, as the subtle rendering differences between modes create false positives in the visual diff.

Accessibility testing tools like axe-core and Lighthouse work correctly in both headless and headed modes, since they analyze the DOM and ARIA attributes rather than visual output. However, testing real screen reader behavior, keyboard navigation focus indicators, hover states, and animation-dependent accessibility features may require headed mode to observe the full user experience as assistive technology users would encounter it.

When to Use Each Mode

Use headless mode for CI/CD test execution, server-side automation, production web scraping, screenshot and PDF generation services, performance monitoring, and any environment without a physical display. Use headed mode for developing and debugging scripts, visual regression testing (if your baseline was captured in headed mode), accessibility audits that require observing visual behavior, and troubleshooting anti-bot detection issues where you need to see the blocking mechanism in action.

Many teams use both modes in a single project. Local development happens in headed mode for the fast visual feedback loop. CI/CD pipelines run in headless mode for speed and compatibility with display-less servers. When a CI test fails, developers can reproduce it locally in headed mode to see what went wrong, or review Playwright trace files that provide after-the-fact visual debugging of headless runs. This dual-mode approach gives you the best of both worlds without requiring any code changes beyond a single configuration flag.