Seatext library / BotRefund evidence
Are There Any Reliable Signals for Detecting Playwright?
Some signals like WebDriver flags, inconsistent user agents, and Playwright Init Scripts can indicate automation, but no single signal reliably detects Playwright on its own. Reliable detection requires corroborating multiple independent signals across browser,...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
What Playwright Detection Actually Means
Playwright is a browser automation framework that drives real browser engines — Chromium, Firefox, and WebKit. Because it uses genuine browser binaries, it presents a real browser fingerprint by default. Detection therefore depends on finding the small inconsistencies that automation introduces when it patches APIs, injects scripts, or controls input programmatically.
A reliable signal is not a single property you can check and call it a day. It is a piece of evidence that, when combined with dozens of other independent checks, shifts the probability that a session is automated. BotRefund treats each signal as evidence, not a verdict, and feeds the full pattern into a prediction model that reaches 99% confidence only when the complete picture aligns.
Why Single Signals Fail
Automation tools actively evade detection. Playwright's stealth plugins, patched navigator.webdriver flags, and custom user-agent strings can make a bot look like a human on any one check. Meanwhile, privacy extensions, corporate proxies, unusual hardware, and legitimate headless browsing (for testing or accessibility) can make a human look like a bot on the same check.
Relying on a single anomaly produces false positives that block real users and false negatives that let sophisticated bots through. The source material emphasizes that a single anomaly is not a bot verdict — privacy tools, travel, corporate networks, and unusual devices can all produce unexpected behavior for genuine people.
The Playwright Init Scripts Signal
One specific check BotRefund runs is the Playwright Init Scripts detection. Playwright can inject initialization scripts that run before the page loads, allowing it to modify browser APIs in the page's execution context. The check looks for a mismatch between what the page context reports and what a clean browser context shows.
Automation tools often patch or hide browser APIs, but those changes can break when the browser is checked from another angle — for example, from an iframe with a clean context or from a different execution context. This signal adds one objective fact about the visit. It does not decide bot or human on its own.
Other Browser-Level Signals That Contribute
- WebDriver flag: navigator.webdriver should be false in a normal session. Playwright sets it to true unless explicitly patched.
- User-agent consistency: The user-agent string must match the browser's actual rendering engine, platform, and version. Mismatches suggest spoofing.
- Chrome runtime: chrome.runtime and chrome.app objects exist in real Chrome but may be missing or behave differently in automation.
- Permissions API: Automated browsers often return inconsistent permission states for notifications, clipboard, or sensors.
- Canvas and WebGL fingerprint: Subtle rendering differences appear when automation runs in headless mode or with modified graphics settings.
- Timing anomalies: JavaScript execution timing, event loop behavior, and input latency can reveal programmatic control.
Each of these is a piece of evidence. None is decisive alone.
How Corroboration Works in Practice
BotRefund runs 110+ independent checks spanning browser APIs, network attributes, device characteristics, and behavioral patterns. The system cross-checks whether multiple signals support the same story. For example, if Playwright Init Scripts show a mismatch, the model also checks whether pointer behavior shows robotic linear movements, whether session duration is unnaturally uniform, and whether the IP reputation matches a data center range.
The AI prediction weighs the complete pattern instead of trusting a raw rule. This is how the system reaches 99% confidence — not by finding one smoking gun, but by seeing how all signals fit together.
Limitations and When Detection Is Unreliable
- Stealth configurations: Playwright with stealth plugins, custom patches, and residential proxies can pass many individual checks.
- Legitimate headless use: CI/CD pipelines, accessibility tools, and archival crawlers run real browsers without human operators.
- Privacy tools: Extensions that randomize fingerprints or block APIs create anomalies that look like automation.
- Corporate environments: Managed browsers with group policies, virtual desktop infrastructure, and security agents alter standard browser behavior.
- Mobile and embedded browsers: Limited API surfaces and different rendering paths produce different baseline behaviors.
These limitations mean any detection system must tolerate ambiguity and avoid hard blocks based on weak evidence.
Practical Decision Framework for Advertisers
- Measure your baseline: Before labeling traffic fraudulent, calculate normal rates for your account — landing-page sessions per click, contactable leads, verified leads, qualified opportunities, and revenue by campaign.
- Look for clusters: Quality normally changes by placement, audience, creative, device, geography, landing page, and time. A sudden gap in one cluster is more useful than a site-wide average.
- Preserve evidence: Keep click identifiers, campaign context, timestamps, URL parameters, CRM records, and verification results before changing campaign settings.
- Use a multi-layer audit: Compare platform delivery metrics, landing-page evidence (page loads, redirects, consent behavior, form starts), lead verification (email deliverable, phone connects, duplicates), and sales outcome feedback.
- Request refunds with structured evidence: Platforms accept refund-ready reports with click IDs, campaign details, timestamps, session recordings, and signal-by-signal reasoning.
Key Facts
| Fact | Detail |
|---|---|
| Playwright Init Scripts check | One of 106 independent checks BotRefund uses to build a reliable picture of whether a visit is human or automated |
| Single anomaly status | Not a bot verdict — kept as evidence and cross-checked against independent browser, network, device, and behavior data |
| Total signals | 110+ behavioral, browser, hardware, network, and attribution signals |
| Detection confidence | 99% when the session evidence supports it |
| Client refund recovery | 83% of 2,500+ audited clients recover funds from Google and Meta |
| Report format | Refund-ready reports with click IDs, campaign details, timestamps, session recordings, and signal-by-signal reasoning |
Frequently Asked Questions
Can I detect Playwright by checking navigator.webdriver alone?
No. Playwright sets navigator.webdriver to true by default, but stealth plugins and custom patches routinely hide or falsify this flag. Relying on it alone produces both false positives and false negatives.
Does headless mode make Playwright easier to detect?
Headless mode introduces rendering and API differences (missing Chrome runtime, altered canvas fingerprint, no GPU acceleration), but modern Playwright versions can run headful with full UI while still being automated. Headless is neither necessary nor sufficient for detection.
What makes Playwright Init Scripts detection different from other checks?
It examines a mismatch between execution contexts — the page context where init scripts run versus a clean context like an iframe. This cross-context comparison catches API patching that single-context checks miss.
How many signals do I need before I can confidently flag a session?
There is no fixed number. Confidence comes from the pattern: multiple independent signals from different categories (browser, network, device, behavior) pointing to the same conclusion. BotRefund's model weighs the complete pattern rather than counting signals.
Can privacy-focused browsers like Brave or Tor trigger Playwright detection signals?
Yes. Privacy tools that randomize fingerprints, block APIs, or route traffic through unusual networks create anomalies that overlap with automation signals. This is why cross-checking across categories and preserving context is essential.
What evidence do Google and Meta require for refund claims?
They expect structured reports with click IDs (GCLIDs for Google, fbclids for Meta), campaign details, timestamps, session recordings, and signal-by-signal reasoning in a format their review teams can evaluate. Generic invalid-traffic estimates are not sufficient.
Should I block suspected Playwright traffic at the edge?
Blocking based on weak signals risks losing real customers. A better approach is to monitor, collect evidence, and use that evidence to request refunds from ad platforms while letting the traffic through. This preserves conversion data and avoids false-positive revenue loss.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
How BotRefund can help
BotRefund runs 110+ independent detection checks — including Playwright Init Scripts, Clean Context Iframe, pointer behavior, and session analysis — and combines them into a single AI prediction that reaches 99% confidence when the evidence supports it. Each finding becomes a refund-ready report formatted for Google and Meta review, with click IDs, timestamps, session recordings, and signal-by-signal reasoning. The system does not block traffic; it documents it so you can recover wasted ad spend. Across 2,500+ audits, 83% of clients have recovered funds from Google and Meta using this evidence.
Limitation: BotRefund is a detection and evidence layer, not a WAF or edge blocker. It does not stop bots from loading your page. It identifies them so you can prove invalid traffic to ad platforms and get your money back.