How the stealth plugin works
The plugin is modular: each evasion is a separate module applied to every new page. Documented modules include one that normalises navigator.webdriver (newer versions return undefined via a Proxy to match a real browser, and add a launch flag that disables the automation-controlled blink feature), a user-agent override that rewrites the HeadlessChrome token out of the UA and aligns related headers, and patches to navigator.plugins, navigator.vendor, webgl.vendor, media codecs, chrome.runtime, and iframe and window properties. All of these work by injecting or patching JavaScript in the page context, fixing the surface that plain Puppeteer leaves with obvious headless markers.
Why JavaScript-only is not enough anymore
The plugin's defining limitation is that it patches only the JavaScript surface. It does not modify network-layer signals - the TLS fingerprint, IP reputation, or HTTP/2 fingerprint - and it cannot fix the deeper graphics tell: headless Chromium typically renders through a software renderer, so the real WebGL characteristics remain a SwiftShader-style tell that a JavaScript webgl.vendor override cannot fully mask. The plugin's own documentation frames detection as a cat-and-mouse game and acknowledges that preventing all of it is probably impossible. Against modern detection stacks, JavaScript-only evasions are widely considered insufficient on their own.
Maintenance status
puppeteer-extra-plugin-stealth is mature but effectively stale. Its last meaningful release is some years old and the repository's activity has slowed, so a number of its individual evasions are outdated relative to current Chrome versions and current detection techniques. It remains widely referenced and is a useful illustration of which JavaScript markers headless automation exposes, but it should not be relied on as current protection. Newer, narrower tools like rebrowser-patches address specific signals it never covered, and the deeper signals it cannot touch are unchanged.
