Playwright Without Detection: A Practical Checklist That Works

The short answer: stealth is a checklist, not a plugin

There is no single switch that makes Playwright undetectable. The realistic goal is to reduce the number of mismatches a bot-detection system can find. This article gives you an ordered implementation checklist, the prerequisites, and one way to verify your work.

Detection services such as BotRefund do not look for one "bot tell". They look for a cluster of evidence across browser, network, device, and behavior data. One anomaly is not a verdict. So your job is to make the whole browser session behave like a normal human session.

Before you start: what you need

• A Playwright project that already works. Get your script working without stealth first. Stealth is a layer on top, not a starting point.
• A recent version of Playwright. Keep it updated. Older versions leak more signals.
• A real browser profile to model. Study how a human browser behaves, then mimic it.
• A test target. Use a detection demo page to verify your setup. Do not test only on the site you intend to automate; you risk being blocked before you learn anything.

The 7-step readiness checklist

1. Install and configure a stealth plugin. Playwright patches some automation signals, but not all. A dedicated stealth plugin (for example, playwright-extra with the stealth plugin) hides common markers such as navigator.webdriver.
2. Disable or manage the headless mode. Headless Chromium is easier to detect than headed mode. Use headed mode when possible, or use the new headless mode if the site allows it. This is one of the first checks a detector can run.
3. Rotate user-agents and viewport settings. A desktop user-agent should match a desktop viewport, and a mobile user-agent should match a mobile viewport. Mismatches are easy signals.
4. Handle cookies and storage. Load a realistic cookie jar. A fresh session with no cookies is not normal for a returning user. Use context.addCookies() or persist a browser context between runs.
5. Fix WebDriver and CDP leaks. The property navigator.webdriver is the classic leak. Stealth plugins handle this, but verify it yourself. Also check window.chrome, permissions, and plugins list.
6. Add human-like delays and actions. Real users move the mouse, scroll, pause, and type with variable speed. Add realistic waits. Do not click at machine speed with zero variation.
7. Rotate IP and proxy behavior carefully. Datacenter IPs are a known signal. If you rotate proxies, make sure the IP matches the browser language, timezone, and locale. A US IP with a Europe timezone is a mismatch.

Why stealth often fails anyway

This is the part most guides skip. Detection systems do not trust a single browser property. They cross-check several angles.

Consider BotRefund's Playwright Init Scripts check. It is one of 106 independent checks. The idea is simple: automation tools patch or hide browser APIs, but those changes can break when the browser is checked from another angle. A normal browser runs standard APIs as designed. An automated browser often shows a patch that only works from one direction.

That is why a plugin that passes one detection demo page can still fail on a site that uses a different detection method. A single anomaly is not a verdict, but a cluster of anomalies is.

How to verify your setup (one concrete step)

Run your script against a detection demo page, then check three things in the returned report:

1. Is navigator.webdriver false? If it is true, your stealth plugin is not working.
2. Does your user-agent match your viewport and platform? A Mac user-agent with a Windows-specific WebGL renderer is a mismatch.
3. Are there any "suspicious" flags for CDP, headless, or missing plugins? If yes, fix that one signal and re-run.

Do not stop at one demo page. Try two or three different detection demos. A setup that passes all of them is much more durable.

The main options and trade-offs

• Stealth plugin vs. manual patches. A plugin is faster and covers the common leaks. Manual patches give you control but take time and break on browser updates.
• Headed vs. headless. Headed is harder to detect but slower and needs a display. Headless is convenient but easier to flag.
• Fresh context vs. persisted profile. A fresh context is clean but looks like a new visitor every time. A persisted profile looks more human but can carry old cookies and storage that cause other issues.
• Home IP vs. proxies. Home IP is realistic but limited. Proxies scale better but introduce IP reputation risk.

Key facts: what bot detection really checks

Limitations: when this advice does not apply

Stealth practices do not guarantee success. They reduce the chance of detection. A determined detection system with cross-checked evidence will eventually flag a session that has too many mismatches.

The advice also changes with your use case. Testing your own site does not need stealth at all; Playwright is a legitimate testing tool. Scraping a competitor's site may violate terms of service. That is a legal and policy issue, not a technical one.

BotRefund's own documentation is honest about this. A single anomaly is not a bot verdict. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. Detection services keep signals as evidence, not verdicts, and cross-check them.

Terminology you will see

• User-agent: A string that tells the website which browser and operating system you are using.
• Headless mode: Running a browser without a visible window.
• CDP (Chrome DevTools Protocol): The protocol Playwright uses to control the browser. Its presence is a detection signal.
• WebRTC leak: A way websites can read your real IP address even when using a proxy.
• Fingerprinting: Collecting many small browser properties to identify a unique browser.

FAQ

Does using Playwright with stealth guarantee I will not be detected?

No. Stealth reduces the number of anomalies, but a detection system that cross-checks browser, network, device, and behavior data can still flag a session. There is no guarantee.

Is headless mode the main reason I get detected?

It is a common reason, but not the only one. The navigator.webdriver flag, CDP presence, and inconsistent user-agent details are equally common leaks.

What is the cheapest way to start?

Start with the free layers: use a stealth plugin, run headed mode, match your user-agent to your viewport, and seed cookies. Test on a detection demo page before testing on your real target.

How do I know if my stealth setup works?

Run it against a detection demo page and read the report. If the report shows WebDriver or headless flags, fix those signals and re-run. Try more than one demo page.

Should I use a proxy?

Only if you need IP rotation or geo-targeting. A proxy adds its own risk: datacenter IPs are a known signal, and a proxy that mismatches your browser timezone creates a new anomaly.

Is stealth the same for scraping and testing?

No. For testing your own site, stealth is not needed. For scraping or automation on sites you do not control, stealth may be against their terms of service.

Final check before you go

Run this five-point sanity check on your script:

1. WebDriver flag is hidden.
2. Headless is off or using the modern headless mode.
3. User-agent, viewport, and timezone match.
4. Cookie jar is realistic.
5. Actions have human-like delays.

If you pass all five on two different detection demo pages, your Playwright setup is about as stealthy as it can reasonably be.