Bot Detection Test

See which automation signals your browser exposes: the webdriver flag, driver globals, headless markers and whether the fingerprinting APIs have been wrapped. A diagnostic for developers and testers. Free, no signup, results stay on this page.

  • Runs entirely in your browser
  • Results are not uploaded
  • No signup

See which automation signals this browser exposes

The check reads the signals a bot filter reads first: the webdriver flag, driver globals left on window and document, headless markers, the plugin and language surface, and whether the APIs used for fingerprinting have been wrapped.

Runs entirely in this browser. Nothing is uploaded, nothing is stored, no signup.

Now give every account its own browser profile.

A clean browser is still one browser. Sendwin runs each profile in isolation with its own fingerprint settings, cookies and proxy, so the accounts you manage stay separate — nothing is shared between profiles.

  • Isolated browser profiles, each with its own fingerprint settings and cookies
  • A proxy per profile, with the timezone bound to the proxy country
  • Windows, macOS and Linux — plus cloud sessions when you need them

Pro from $19/mo, with a 7-day money-back guarantee. The free cloud demo gives you 10 minutes a day.

The question a site asks before any other

Before a site scores anything subtle about your machine, it asks a much cheaper question: is a person driving this browser, or is software? The answers are lying in plain sight. An automated browser announces itself in navigator.webdriver, drivers attach bookkeeping properties to window and document, headless builds ship without the plugin entries every desktop Chromium has, and patched built-in functions stop reporting themselves as native code. None of this requires a login, a mouse movement or a challenge — it is readable on the first page load.

This test runs those checks against the browser you are reading this in and names what it finds. It is the same group the full fingerprint checker runs, on its own page, because the question it answers is specific: not how identifiable you are, but whether this browser looks driven. If you build or test with a browser automation framework and want to know which of these signals your test browser exposes, this is the list to read.

What the cheap checks actually look at

navigator.webdriver is the one the specification defines for exactly this purpose, and an unconfigured automated browser sets it to true. Beyond that, each driver leaves traces of its own: ChromeDriver's cdc_ properties, Selenium's recorder hooks, Playwright's and Puppeteer's internal handles, all readable as ordinary properties on window or document. A headless build gives itself away structurally — desktop Chromium synthesises a fixed set of built-in PDF entries in navigator.plugins, and an empty list on a desktop Chromium user agent is not a configuration anyone chose. An empty navigator.languages means the browser launched with no profile behind it, and a window reporting zero outer dimensions means there is no real window around the page at all.

Why overwritten values are a signal of their own

Overwriting the values a site reads leaves traces of its own, and the integrity checks on this page read those traces. A replaced built-in function no longer prints as native code, and asking is a single call — so a getImageData or getParameter that has been wrapped to return friendlier answers reports the wrapping to anyone who looks. Stack traces are the same story: rewrite them to hide injected frames and they stop matching the layout the engine actually produces. And the classic headless Chromium bug is still worth testing for, where the Notification API and the Permissions API return different states for the same stored permission — two answers to one question, from a browser insisting nothing is unusual.

A server or a VM is not a bot, and this page keeps them apart

One distinction gets flattened almost everywhere else, and it matters if you run browsers on rented hardware. Rendering without a GPU — SwiftShader, llvmpipe, the Microsoft Basic Render Driver — is what you get on a VPS, inside a virtual machine, over remote desktop, or with hardware acceleration switched off. It makes a session stand out from everyday traffic, because most visitors reach real hardware. It is not evidence that anything is driving the browser, and this test does not treat it as such: the GPU is read by the WebGL report, which reports it as an environment signal, and nothing on this page counts it as automation. A tool that tells you a work laptop with hardware acceleration off is a bot has just taught you to ignore it.

What the check runs

  1. 1

    Read the declared flags

    The check starts with what the browser volunteers: navigator.webdriver, automation and headless tokens in the user agent string, and the driver bookkeeping properties left on window and document.

  2. 2

    Check the shape of the runtime

    Then the structural signals — the plugin and MIME surface, the accepted-language list, the window's outer dimensions, and whether the Chromium runtime object is present on a browser claiming to be Chromium.

  3. 3

    Test the built-ins for tampering

    Finally the integrity checks: whether the APIs used for fingerprinting still report themselves as native code, whether stack traces match the engine, and whether the two permission APIs agree with each other.

Bot detection FAQ

What these checks read, why a value changed in isolation stands out, and why running on a server is not the same as being a bot.

It is the set of checks a site runs to decide whether a request came from a person or from software. The cheap end reads what the browser declares about itself — the webdriver flag, automation properties, headless markers — and the expensive end watches timing and behaviour over a session. This page covers the cheap end, because that is the part that is decided before you have done anything at all, and the part you can actually inspect.

Because these are only the signals readable from JavaScript on a single page load, and a browser can expose none of them. They do not include what a site learns from your IP address and its reputation, from TLS and HTTP/2 handshake fingerprints below the browser, or from how a session behaves over time. A clean result here means the signals this page reads are absent, not that the browser is indistinguishable from one a person is using.

Usually, through its defaults. Headless Chromium sets the webdriver flag, ships an empty plugin surface, and often launches with no language list and no window dimensions — all of which this page reads. A headless build whose values have been rewritten exposes a different signal instead: built-in functions that no longer report as native code, and values that disagree with each other. The page reads for both, which is why it checks the shape of the runtime and the integrity of the built-ins and not only the declared flags.

Not by anything on this page. A software rasterizer means the browser could not reach a GPU, which is ordinary on a VPS, in a virtual machine, over remote desktop or with hardware acceleration turned off. It does make a session distinctive, because most everyday visitors render on real hardware, so it is worth knowing about — but it is a statement about the machine, not about who is driving the browser, and we deliberately keep the two apart. The WebGL report covers it as an environment signal.

It is a standard property that reports whether the browser is under automation control, and it exists precisely so sites can ask. Automation frameworks set it, and every bot filter reads it first. It is also the easiest of these signals to switch off, which is why on its own it proves very little in either direction, and why the rest of the checks on this page exist.

Yes — that is what the page is for. Point the browser your test suite drives at this page, let the check run and read the rows: each finding names the property or behaviour it found and the software it belongs to, so you know exactly which signals that environment exposes to the sites it runs against. It is a checklist of what is currently visible, not a certificate — the limits in the second question above still apply.

No. Every check runs in your browser, the findings exist only in the page in front of you, and reloading clears them. There is no account and nothing to delete afterwards.

Still have questions? Talk to us →

How to read a clean result

Read a clean result as “the signals readable from JavaScript on this page are clean”, and nothing wider. This page cannot see your IP reputation, the TLS and HTTP/2 fingerprints your connection produces below the browser, or how a session behaves over time — all of which real bot filters weigh, and none of which a page can measure about itself. It is a checklist of what is visible from here, not a verdict from any particular platform.

Isolated profiles, built in rather than patched on.

Sendwin runs each profile in a full browser with its own fingerprint settings, cookies and proxy, applied at the engine level rather than wrapped after the fact. Pro from $19/mo on Windows, macOS and Linux.

Signed Windows & macOS builds · patched-Chromium engine · EU cloud server (Finland)

7-day money-back guarantee on your first card purchase · cancel anytime — your profiles stay on your machine

Try the cloud demo →See plans