What Indicators Do Websites Use to Detect Playwright?

Websites typically detect Playwright by checking for a few well-known browser signals: the navigator.webdriver flag, missing plugins, a headless user-agent, and cursor or click patterns that do not look human. No single signal is enough. Serious detection systems look for contradictions between what a browser says and what it does, then cross-check the evidence against other data.

Playwright is a browser automation framework used for testing, scraping, and repetitive web tasks. It controls real Chromium, Firefox, or WebKit browsers, which makes it harder to detect than old-style HTTP bots. Automated browsers still leave traces. This article explains the indicators websites use, why they matter, and how to read the results without jumping to a verdict.

What does it mean for a website to detect Playwright?

Detection rarely means that the site knows the software is named Playwright. It means the site sees a pattern that matches an automated browser. That pattern can come from browser properties, rendering behavior, network context, or user interaction.

A website can run its own script before the page content loads. This is often called an init script. The script watches for changes that automation tools make to the browser. BotRefund calls one version of this a Playwright Init Scripts check and uses it as one of 106 independent checks.

Typical indicators websites use

The list below covers the most common signals. A single indicator is not a verdict, but a cluster of them can be strong evidence.

• navigator.webdriver: This browser property often appears true in automated browsers. A real user's browser usually returns false or undefined.
• User-agent string: Headless browsers often send a user-agent that names headless. A user-agent that conflicts with the installed browser version is another clue.
• Plugins, fonts, and languages: Normal browsers expose a set of plugins, fonts, and language settings. Automated browsers can show none or a generic set.
• API consistency: Automation tools often patch or hide browser APIs. Those patches can break when the site checks the browser from another angle.
• Rendering context: Screen size, WebGL, canvas, and permission behavior can report small inconsistencies in automated environments.
• Pointer and keyboard behavior: Human movement is noisy. Automated cursors often move in straight lines, and click timing can be too regular.
• Network and hardware context: IP address, screen size, hardware sensors, and device type add context. BotRefund combines 110+ behavioral, browser, hardware, network, and attribution signals.

Why one signal is never enough

A single anomaly is not a bot verdict. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. A VPN can change network signals. A corporate browser can block plugins. A user with extensions can look different from a default browser.

If a site blocked everyone with one mismatch, it would block real customers. That is why serious detection systems use corroboration. They collect several independent facts and ask whether they tell the same story.

How a Playwright init script check works

A normal browser runs standard browser APIs as designed. Its built-in properties, permissions, and rendering contexts remain consistent without needing to hide automation. A Playwright automation session often needs to patch or hide those APIs. The patch can break when the website checks the browser from a different context.

Concretely, the site might compare a property in the main frame and an iframe, call the same function in different ways, or inspect the object descriptor. If the values disagree, the site records a mismatch. This is the Playwright Init Scripts signal.

BotRefund then sends that signal into a prediction model that evaluates the complete picture across browser, network, device, and behavior evidence. The signal is evidence, not a verdict.

Server-side vs client-side detection

Server-side audits look at server log files. They monitor IP addresses, request headers, and user-agent data. This catches basic scraper bots, but it struggles to detect advanced botnets.

Client-side audits analyze the visitor's browser behavior. For Playwright, client-side checks matter more, because the network layer can look normal while the browser itself reveals automation.

Key facts about this detection signal

The table below summarizes what BotRefund's documentation says about Playwright detection and the way this signal fits into a larger system.

Playwright detection readiness checklist

Use this checklist before you decide whether a session is automated. The goal is evidence, not a quick verdict.

• Check the webdriver flag in multiple frames.
• Compare the user-agent to the browser version.
• Look at plugins, fonts, and language settings.
• Probe browser APIs from more than one context.
• Watch pointer path, click timing, and typing cadence.
• Add network, hardware, and device context.
• Cross-check the anomaly before blocking or refunding.

If any signal conflicts with the others, investigate further. One odd value is a lead, not a conclusion.

Practical scenarios

These are illustrative scenarios, not customer stories.

Scenario 1: A tester runs a Playwright checkout test. The browser comes from a data-center IP, uses a headless user-agent, and has no plugins. The site sees several signals pointing to automation. The session may be blocked even though the tester's intent was legitimate.

Scenario 2: A traveler uses a VPN and a corporate-managed browser. The network signal looks odd, fonts are missing, and the user-agent is unusual. A raw rule-based system could flag a real person. A detection system that cross-checks signals should keep the session in the human bucket.

Limitations and when this advice does not apply

No indicator is proof by itself. The documentation is explicit: a single anomaly is not a bot verdict. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people.

If your site is small and has no bot problem, you may not need any of this. If you are testing your own site with Playwright, a simple header or test account may be enough. For ad accounts, automated traffic can contaminate optimization and raise costs, but the signal must be confirmed by campaign context.

Common terms

• Playwright init script: A check that runs at browser initialization and looks for mismatches caused by automation tools.
• navigator.webdriver: A browser property that websites can read to detect automation.
• User-agent: A browser string that identifies the browser and operating system.
• Headless browser: A browser that runs without a visible window.
• Client-side audit: An analysis that runs in the visitor's browser and observes behavior.
• Server-side audit: An analysis of server logs, IP addresses, request headers, and user-agent data.

Frequently asked questions

Can websites detect Playwright even when stealth options are used?

Yes. Playwright patches or hides APIs, but those changes can break when the browser is checked from another angle. No stealth script guarantees invisibility.

Is navigator.webdriver always true in Playwright?

Not always. The value can appear in different forms depending on how the browser is launched, but it is one of the common checks websites use.

What should I do if a website blocks my Playwright script?

Look at the full evidence: user-agent, browser context, mouse patterns, and network properties. Fix the specific mismatch, and remember that a high-security site may still block you.

How many signals do bot detection services use?

BotRefund says it combines 110+ signals and that its Playwright check is one of 106 independent checks.

Does a missing plugin prove a user is a bot?

No. A single anomaly is not a bot verdict. A plugin can be missing because of privacy settings, corporate policy, or an unusual device.