Which Headless Browsers and Automation Frameworks BotRefund Detects

BotRefund detects headless Chrome, Firefox, and WebKit browsers, along with the automation frameworks that drive them — Playwright, Puppeteer, and Selenium. It does this through 106 independent client-side checks that examine browser APIs, rendering behavior, input patterns, and network context. Each check contributes one piece of evidence; the final verdict comes from an AI model that weighs the complete pattern across browser, network, device, and behavior signals. This corroboration approach is why BotRefund reaches 99% confidence in the bot traffic it flags.

What BotRefund's detection actually covers

BotRefund's detection runs in the visitor's browser, not at the network edge. That means it sees the same JavaScript environment a human user sees — including any modifications automation tools make to hide their presence. The system runs 106 independent checks grouped into browser consistency, behavioral biometrics, network context, and device fingerprinting. No single check decides the outcome. Instead, each check adds an independent fact that the prediction model evaluates together.

The checks target anomalies that appear when automation frameworks patch or hide browser APIs. For example, the Playwright Init Scripts check looks for mismatches that a real browsing session does not normally create. The Clean Context Iframe check tests whether browser APIs behave consistently when accessed from a clean iframe context. The Scrollbar Width Leak check examines whether scrolling behavior matches human variability. These are three of the 106 checks; others cover pointer movement, click timing, rendering details, and navigation flow.

How the detection works in practice

When a visitor lands on a page protected by BotRefund, the client-side script runs its suite of checks silently. Each check returns a signal — for instance, whether the navigator.webdriver property is present, whether mouse movements show humanlike tremor, or whether the browser's rendering context matches a known headless profile. The signals are sent to BotRefund's prediction engine, which has been trained on millions of labeled sessions across 2,500+ brand audits.

The engine does not apply hard rules like "if navigator.webdriver equals true, block." Privacy tools, corporate proxies, and unusual devices can trigger individual signals for genuine users. Instead, the model weighs how all signals fit together. A headless Chrome instance running Puppeteer with stealth plugins might pass the webdriver check but fail on pointer behavior, scroll timing, and iframe context consistency simultaneously. That cluster produces a high-confidence bot classification.

Automation frameworks and headless engines BotRefund identifies

BotRefund's checks are designed against the behaviors of the most common automation stacks:

• Playwright — explicitly targeted by the Playwright Init Scripts check, which detects initialization scripts and API patches that Playwright injects.
• Puppeteer — shares the same Chrome DevTools Protocol foundation as Playwright; the same browser-consistency checks catch its modifications.
• Selenium — typically drives full browser instances (headed or headless) via WebDriver; the WebDriver-specific signals and behavioral checks detect it.
• Headless Chrome — whether launched directly via --headless flag or through a framework, the rendering and API differences from a headed Chrome build are caught by multiple checks.
• Headless Firefox — similar rendering and API surface differences appear under headless mode; cross-browser checks cover both engines.
• Headless WebKit — used by some scraping tools and Playwright's WebKit channel; the same consistency and behavioral checks apply.

The system does not maintain a static list of user-agent strings or version numbers. It detects the behavioral and structural artifacts that automation leaves behind, which means it catches custom-built headless setups and less common frameworks that exhibit the same anomalies.

Decision criteria for choosing a bot detection approach

If you are evaluating whether BotRefund's detection fits your needs, use these criteria:

Criterion	What to look for	Why it matters
Detection layer	Client-side (browser) vs. server-side (logs/CDN)	Client-side sees automation's browser modifications; server-side only sees network traces.
Signal breadth	Number and independence of checks	More independent signals reduce false positives; BotRefund uses 106+.
Verdict method	Rule-based vs. AI-weighted pattern	AI weighing handles edge cases (privacy tools, corporate networks) better than hard rules.
Evidence output	Raw logs vs. refund-ready reports	Google and Meta require structured evidence with click IDs, timestamps, and session recordings.
Refund track record	Published success rate with ad platforms	BotRefund clients recover funds in 83% of audits across 2,500+ brands.
Integration effort	Script tag vs. infrastructure change	BotRefund adds a script tag; no DNS, CDN, or server changes required.

Comparison: client-side behavioral detection vs. common alternatives

Approach	Best fit	Setup effort	Core workflow	Control & customization	Limitations
BotRefund (client-side behavioral)	Advertisers needing refund-ready evidence for Google/Meta	Low — single script tag	Detect → record → generate platform-formatted report → negotiate refund	Configure sensitivity; whitelist known tools; custom signal rules	Requires JavaScript execution; cannot block at network edge
Cloudflare / WAF (edge fingerprinting)	Infrastructure teams blocking malicious traffic pre-request	Medium — DNS/CDN changes	Challenge/block at edge based on TLS fingerprint, IP reputation, headers	Firewall rules, rate limits, managed rulesets	Misses sophisticated headless browsers that mimic real clients; no refund evidence
Server-side log analysis	Post-hoc traffic audits	Low — existing logs	Parse logs for IP patterns, user-agent anomalies, request velocity	Custom queries, SIEM integration	Cannot see browser-level automation artifacts; high false negatives for advanced bots
Generic CAPTCHA / challenge	Low-stakes form protection	Low — widget embed	Challenge suspicious interactions	Limited — difficulty, trigger rules	Harms conversion; bots solve CAPTCHAs; no evidence for ad refunds

Takeaway: If your goal is recovering ad spend from Google and Meta, you need client-side behavioral evidence formatted for their review teams. Edge blocking and log analysis do not produce that evidence. CAPTCHAs hurt conversion and do not create audit trails.

Practical scenarios where detection matters

Scenario 1: Competitor click fraud on Google Ads

A competitor runs a headless Chrome fleet via Puppeteer to click your ads repeatedly. Server-side logs show diverse IPs (residential proxies) and realistic user-agents. BotRefund's client-side checks detect the missing mouse tremor, superhuman click speed (<1ms), and Playwright/Puppeteer API patches. The resulting report includes GCLIDs, session recordings, and signal-by-signal reasoning — the format Google's invalid activity team expects.

Scenario 2: Meta lead form spam from automation

An affiliate network uses Selenium-driven Firefox to submit lead forms at scale. Leads look real in Ads Manager (valid emails, phone numbers) but sales teams cannot reach them. BotRefund catches the uniform form completion timing, absence of scroll behavior, and WebDriver artifacts. The evidence links each submission to a click ID and placement, enabling a Meta refund claim.

Scenario 3: Pixel poisoning from scraper bots

Scrapers using headless WebKit via Playwright visit product pages to harvest pricing. They do not click ads, but they fire your Meta Pixel and Google Ads conversion tags, corrupting optimization algorithms. BotRefund identifies the non-human navigation flow and rendering anomalies, letting you suppress pixel fires for those sessions in real time.

Key facts from BotRefund's source documentation

Fact	Detail	Source
Independent checks	106 browser, network, device, and behavior checks	S1, S3, S4
Total signals	110+ behavioral, browser, hardware, network, and attribution signals	S2
Detection confidence	99% confidence in flagged bot traffic	S1, S2, S3, S4
Brands audited	2,500+	S2
Client refund recovery rate	83% of clients recover funds from Google and Meta	S2
Refund-ready report format	Click IDs, campaign details, timestamps, session recordings, signal-by-signal reasoning	S2
Detection method	Client-side browser-level auditing with AI-weighted pattern recognition	S1, S3, S4, S6
Explicit framework checks	Playwright Init Scripts, Clean Context Iframe, Scrollbar Width Leak	S1, S3, S4
Behavioral signals	Mouse tremor, click speed, pointer path linearity, scroll timing, session duration patterns	S2
Cross-check philosophy	Single anomaly = evidence, not verdict; AI weighs complete pattern	S1, S3, S4

Limitations and when this advice does not apply

• JavaScript required: BotRefund's checks run in the browser. Visitors with JavaScript disabled or strict script blockers will not be fully analyzed. This is a fundamental constraint of any client-side detection.
• Not a network-edge blocker: BotRefund does not terminate TCP connections or modify DNS. It detects and reports. If you need pre-request blocking (DDoS mitigation, WAF), pair it with an edge layer.
• Sophisticated residential botnets: Attackers who run real browsers on real devices with human operators (click farms) may pass behavioral checks. BotRefund focuses on automated traffic; human fraud requires different evidence.
• Privacy tool false signals: Privacy browsers, anti-fingerprinting extensions, and corporate security tools can trigger individual checks. The AI cross-check reduces false positives, but edge cases exist.
• Mobile app traffic: Detection covers web browsers. In-app browsers (WebView) and native app traffic have different signal availability.

Terminology quick reference

• Headless browser: A browser running without a visible UI, typically controlled programmatically.
• Automation framework: Software library (Playwright, Puppeteer, Selenium) that drives browsers via standard protocols (CDP, WebDriver, BiDi).
• Client-side detection: Code executing in the visitor's browser to observe runtime behavior and API surface.
• Server-side detection: Analysis of HTTP logs, headers, IP reputation, and request patterns at the origin or edge.
• Pixel poisoning: Invalid traffic firing conversion pixels, corrupting the training data ad platforms use for optimization.
• Refund-ready report: Evidence package formatted to match Google Ads and Meta Ads invalid traffic claim requirements.
• GCLID / FBCLID: Google Click Identifier / Facebook Click Identifier — attribution parameters appended to landing page URLs.

Frequently asked questions

Does BotRefund detect custom-built headless browsers?

Yes. The checks target structural and behavioral artifacts (API patches, rendering differences, input timing) that any automation leaves, not framework-specific signatures. A custom headless Chrome build will still lack humanlike mouse tremor, show superhuman click speeds, and fail iframe context consistency checks.

Can bots evade detection by using stealth plugins?

Stealth plugins (e.g., puppeteer-extra-plugin-stealth) patch known detection vectors like navigator.webdriver. BotRefund's 106 checks cover many vectors stealth plugins miss — pointer behavior, scroll timing, rendering context, navigation flow. The AI model weighs the full pattern; passing one check while failing five others still yields a bot classification.

What happens if a real user triggers a check?

Individual checks produce evidence, not verdicts. Privacy tools, corporate proxies, and unusual devices can trigger signals for genuine users. The AI model evaluates whether the cluster of signals matches automation or a known legitimate edge case. This cross-check design is why false positives stay low.

How long does detection take?

The client-side script runs asynchronously during the session. Most checks complete within the first few seconds of page load; behavioral checks (mouse, scroll, timing) accumulate over the session. The verdict is available in real time for pixel suppression and in the dashboard for reporting.

Does BotRefund work with single-page applications (SPAs)?

Yes. The script initializes on page load and continues monitoring through client-side route changes. Session recording and signal attribution persist across SPA navigation.

What ad platforms accept BotRefund's evidence?

Google Ads and Meta Ads (Facebook/Instagram) are the primary platforms. Reports are structured to match their invalid traffic claim formats. Other platforms with similar claim processes can use the same evidence.

Can I use BotRefund alongside Cloudflare or another WAF?

Yes. Many advertisers run both: Cloudflare for edge security (DDoS, WAF) and BotRefund for marketing-layer evidence and refund recovery. They operate at different layers and serve different goals.

Next steps

If you run paid campaigns on Google or Meta and suspect invalid traffic, the fastest way to quantify the problem is a free bot audit. The audit runs BotRefund's full detection suite on your live traffic and produces a sample report showing exactly what the system catches — without any commitment to purchase.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

• The Best Headless Chrome Browser for Bypassing Anti-Bot Systems
• Headless Browser Detection: Techniques and Strategies to Outsmart ...
• Headless Browser Detection: How Sites Know You're a Bot - DEV ...

Learn more

Visit the website for more information.