What bot.sannysoft.com and CreepJS actually test, how to read a result row, and why passing them isn't proof against a site's real detection stack.
Search for "am I a bot" and two names come up constantly: bot.sannysoft.com and CreepJS. Both are free, no-signup pages that run a battery of client-side checks and show you the raw result — no hidden score, no explanation required. They're popular with QA engineers testing headless CI pipelines, and with the same automation-tooling authors covered in our guide to bot detection techniques. This guide explains what each page actually checks, how to read a result row, and — importantly — why a clean pass on either one is not the same as passing a real production detection stack.
Key Takeaways
- bot.sannysoft.com runs a quick pass/fail table of classic automation tells:
navigator.webdriver, thewindow.chromeobject, plugin and permission checks, and the WebGL renderer string. - CreepJS goes deeper: it's an open-source project that cross-checks the same browser property from multiple independent code paths and flags "lies" where a stealth patch changed one path but missed another.
- A green row means your browser doesn't trip that specific known tell — it says nothing about behavioral analysis, TLS/HTTP-2 fingerprints, or IP reputation, which a live site also scores.
- Both tools are independent community projects, not products of any browser vendor, and their exact checks change as automation frameworks evolve.
- BrowserInsight's own bot detection tool surfaces many of the same signals for your current browser, with an explanation of what each one means.
What These Public Test Pages Actually Check
Neither page is a commercial product — both grew out of the same research community that documents headless browser detection, and both exist to give anyone a fast, transparent answer to "what does my automated browser leak?"
bot.sannysoft.com is the simpler of the two: load the page and it renders a table where each row is one known automation tell, colored green (looks human) or red (looks automated). It checks things like whether navigator.webdriver reports true, whether the window.chrome object that real Chrome exposes is present, whether navigator.plugins has a plausible non-zero length, whether the Permissions API returns internally consistent answers, and whether the WebGL renderer string points at real GPU hardware rather than a software rasterizer. These are exactly the categories our bot detection techniques guide covers in more depth — Sannysoft's page is a fast way to see them applied to your own browser in one glance.
CreepJS (source at github.com/abrahamjuliot/creepjs) is a much larger, MIT-licensed open-source project built specifically to catch spoofing and stealth tooling, not just bare, unpatched automation. Instead of reading a property once, it reads the same value through several independent code paths — the prototype chain, a Web Worker's isolated scope, an iframe's separate global — and compares them. A real, unmodified browser gives the same answer down every path. A stealth patch that overrides navigator.webdriver on the main thread but forgets the same object inside a worker produces a mismatch CreepJS labels a "lie." That cross-path comparison is what makes it a harder pass than Sannysoft's page for anyone specifically trying to spoof their fingerprint rather than just running unpatched automation.
Reading a Result Row
Both pages present the same underlying idea — observed value versus expected value for a real browser — but format it differently.
On Sannysoft's table, each row names a check and colors it by verdict. The ones worth actually reading: WEBDRIVER (should be false/absent on a real browser), the CHROME row (real Chrome exposes a non-trivial window.chrome object; many automation contexts don't), PLUGINS-LENGTH (a real desktop Chrome install reports a small but non-zero plugin list), the PERMISSIONS row (checks whether a queried permission state is internally consistent rather than contradictory), and the WebGL vendor/renderer rows (a software renderer like SwiftShader instead of a real GPU name is one of the strongest single tells, as covered in our headless browser detection guide).
CreepJS presents an aggregated trust score up top, then breaks results into categories with specific properties flagged individually as consistent or as a detected "lie." A single flagged lie is more informative than the aggregate score — it tells you exactly which spoofing layer failed to cover every code path, which is useful if you're debugging your own automation setup rather than just checking a pass/fail total.
Treat both pages as living projects: their exact row names, categories, and scoring change as maintainers add checks for newly discovered tells, so this is an explanation of the underlying signal categories rather than a fixed manual for one version.
Which Signals Matter vs. Which Are Noise
Not every row carries equal weight:
| Signal | Weight | Why |
|---|---|---|
navigator.webdriver === true | Strong | Real browsers never report this; only unpatched WebDriver sessions do |
| WebGL renderer is a software rasterizer | Strong | Requires real GPU access to fake, which most automation environments lack |
| CreepJS-flagged property "lies" | Strong | Internal inconsistency a real, unmodified browser structurally cannot produce |
| Empty or short plugin list alone | Weak | Privacy browsers and modern Chrome builds intentionally shrink this list too |
| Missing legacy APIs (e.g. Battery Status) | Weak/noise | Increasingly removed or gated in real browsers for privacy reasons, unrelated to automation |
The pattern: signals that require faking something structural about how a browser renders or exposes its own internals are hard to fake and therefore meaningful. Signals that a normal privacy-conscious browser might also trigger are weak on their own — which is exactly the distinction our bot detection techniques guide draws between "one signal" and "a scored combination of them."
How These Test Pages Differ From a Site's Real Detection Stack
A single page load on Sannysoft or CreepJS can only ever measure what a static page can observe: this one browser, this one request, right now. A production detection stack watches much more — mouse and keyboard timing across the whole session, TLS and HTTP/2 handshake fingerprints below the JavaScript layer, IP reputation and request velocity, and how a given fingerprint clusters against thousands of other visitors over time. None of that shows up on a single-page test, because it requires history and network-level visibility that a browser-side page simply doesn't have.
That means a clean sheet on both test pages proves your setup avoids the well-known static tells — genuinely useful for anyone auditing a CI pipeline or automation tool — but it is not evidence you'd pass a live commercial anti-bot system, which layers in exactly the signals a static page can't see. If your automated browser also needs a plausible User-Agent, our guide to detecting user-agent spoofing covers the header- and client-hint-level checks that run alongside everything above.
Check Your Own Browser with BrowserInsight
If you want to see these signals explained for your current browser rather than reading a bare pass/fail table, BrowserInsight's bot detection tool reports your navigator.webdriver state, plugin and permission consistency, and WebGL renderer — each with a plain-language explanation of what it means and why it matters, all computed client-side.
Frequently Asked Questions
Are Sannysoft and CreepJS official tools from Google or browser vendors?
No. Both are independent, community-built projects, unaffiliated with any browser vendor. They're widely used in the bot-detection and automation-tooling community as informal, transparent reference checks — not as an official certification of anything.
If I pass CreepJS's trust score, will I avoid getting blocked by real websites?
Not necessarily. A high trust score means your browser doesn't trip the specific checks CreepJS runs. A live site's anti-bot system also scores behavior, network fingerprints, IP reputation, and history across many requests — none of which a single test-page load can evaluate.
Why do Sannysoft and CreepJS sometimes disagree about the same browser?
They check different things at different depths. Sannysoft focuses on a smaller set of classic, well-known tells; CreepJS cross-checks many properties across independent code paths specifically to catch spoofing that already defeats the simpler checks. A setup can look clean on one and get flagged on the other.
Is it legitimate to use these pages to test my own automation setup?
Yes — that's one of their most common uses. QA teams running headless browsers in CI, and researchers studying detection techniques, use these pages to see exactly what a target site's detection layer might notice about their setup before it ever reaches production.
