Playwright and Puppeteer Browser Fingerprinting

Playwright and Puppeteer Browser Fingerprinting: Headless Detection

For QA teams using browser automation, Playwright and Puppeteer expose detectable fingerprints in headless mode. Both automation frameworks control Chromium through the Chrome DevTools Protocol (CDP), and the resulting browser environment differs from a real user's browser in ways that fingerprinting scripts can measure.

navigator.webdriver is set to true in headless Chromium, advertising the automation context directly.¹ navigator.plugins is empty, which no real desktop Chrome installation reports. The headless User-Agent string contains "HeadlessChrome" rather than "Chrome".² Consequently, sites that run fingerprinting checks can detect automation without any behavioral heuristics; the passive signal profile alone distinguishes a headless browser from a real user.

Building on this, Playwright's real-browser mode using an installed Chrome binary rather than the bundled Chromium reduces some of these differences, but the CDP connection itself introduces artifacts that persistent fingerprinting scripts can detect. Understanding which signals change between real and headless mode is essential for testing automation against sites with bot detection.

What headless Chrome signals fingerprinting scripts detect

Headless Chromium produces several passive signals that distinguish it from a real user's browser, and any one of these signals is sufficient for a fingerprinting script to flag the session as automated. navigator.webdriver returns true, which the WebDriver specification explicitly defines as a boolean that must be set to true during any automation session controlled through the Chrome DevTools Protocol.¹ navigator.plugins returns an empty PluginArray with length 0, while real desktop Chrome installations always include at least the PDF Viewer plugin and typically several others.² The User-Agent string from headless Chromium includes "HeadlessChrome" in the comment section, a substring that is completely absent from real Chrome installations on any platform.

Why automation leaves a recognizable profile

WebGL rendering in some headless configurations uses a software renderer (SwiftShader) rather than GPU hardware acceleration, causing the WEBGL_debug_renderer_info UNMASKED_RENDERER_WEBGL string to return "Google SwiftShader" rather than a real GPU model.³ Consequently, a fingerprinting script that checks any of these four signals can identify the Playwright or Puppeteer context.

Building on this, the canvas hash in SwiftShader mode differs from all hardware-rendered canvases, making it a reliable automation detector independent of the webdriver flag. You can confirm the effect by comparing the hash your headless run produces against the hash from a normal Chrome window on the same machine. Because SwiftShader is a shared software renderer, every headless instance generates the same canvas output, so a fingerprinting script does not need behavioral analysis to reach a confident verdict about the session.

How anti-bot systems identify automation

Anti-bot systems combine the passive fingerprint profile with behavioral and timing signals to classify visitors. On the fingerprint side, the combination of webdriver=true, empty plugins, and a SwiftShader WebGL renderer is an unambiguous automation signal. On the behavioral side, mouse movement trajectories in automation differ from human movements; they often follow straight lines or programmatic curves, lack the micro-jitter of real hand movement, and arrive at click targets with unrealistic precision.

How to keep testing honest

Yet even without behavioral analysis, the fingerprint profile alone is sufficient for basic detection. Building on this, the absence of GPU hardware acceleration means the canvas hash computed in headless mode is deterministic and matches the SwiftShader hash that all headless Chrome instances produce, making it a shared signature across all automation runs regardless of the test machine. Furthermore, the CDP WebSocket connection metadata is available to server-side code, and some advanced bot detection services fingerprint the CDP protocol characteristics in addition to the browser environment.

Reducing detection in automation testing

For automation used to test sites that have bot detection as a side effect of fingerprinting, several modifications reduce the detection surface. Setting navigator.webdriver to false via CDP Page.addScriptToEvaluateOnNewDocument prevents the most obvious detection signal by removing the automation flag before any page script executes.⁴ Passing a realistic User-Agent string through the browser launch options removes the "HeadlessChrome" substring that immediately identifies the headless context.

Using Playwright's launched-browser mode with the system-installed Chrome binary rather than the bundled Chromium enables full hardware GPU acceleration, which replaces the SwiftShader software renderer with a real GPU renderer and produces a canvas hash that matches what a real user's Chrome browser generates on that specific machine, while also populating the navigator.plugins array with the actual plugin list from the system Chrome installation rather than returning an empty array.⁵

What still needs manual verification

Consequently, the passive fingerprint of an automation session using a real Chrome binary matches a real user on that machine far more closely than headless Chromium with default settings, because the GPU-rendered canvas hash, the real WebGL renderer string, and the authentic plugin list all align with what a legitimate Chrome installation produces on that specific hardware. Building on this, injecting realistic plugins via the navigator.plugins override prevents the empty plugins anomaly that would otherwise signal automation. These techniques are documented here for quality assurance and compatibility testing purposes, not for bypassing access controls on third-party services. CapyToolkit can compare the adjusted automation fingerprint with a real-browser baseline so you can verify which signals remain unrealistic.

When to use this

Use this guide when building browser automation that needs to behave like a real user for QA testing on sites where bot detection interferes with test execution, or when diagnosing which headless signals an automated test exposes to fingerprint-based blocks.

Examples

Default Playwright headless launch: `navigator.webdriver` === true (set by the WebDriver spec; detectable by any fingerprinting script)

Using Page.addScriptToEvaluateOnNewDocument to delete `navigator.webdriver` before page scripts run: `navigator.webdriver` === undefined (no longer exposes the automation flag)

Playwright with bundled Chromium (SwiftShader): canvas hash = [SwiftShader deterministic hash, same on every machine]

Playwright with system Chrome binary and GPU enabled: canvas hash = [real GPU-rendered hash, matches the machine's Chrome browser]