How do I tell if a website uses an A/B testing tool?

Open DevTools, go to the Network tab and reload — experimentation tools load a script from their own domain, such as cdn.optimizely.com (Optimizely) or dev.visualwebsiteoptimizer.com (VWO). You can also open the Console and check for their global object, like typeof window.optimizely. View Source and searching for the provider domain works too, and an anti-flicker snippet at the top of the head is a strong supporting clue.

What is the anti-flicker snippet and why does it matter?

It is a small inline script and style placed high in the page's head that briefly hides the body (or sets it to opacity 0) until the A/B testing tool has loaded and applied its changes. Without it, visitors would see the original page flash before the variation swaps in. Spotting that hide-then-reveal pattern in View Source is a strong sign a synchronous experimentation tool is installed, even before you identify which one.

Which signals identify Optimizely versus VWO?

Optimizely loads from cdn.optimizely.com and exposes a window.optimizely object you can inspect in the Console. VWO (Visual Website Optimizer) loads from dev.visualwebsiteoptimizer.com, exposes window._vwo_code and a VWO object, and sets cookies beginning with _vwo and _vis_opt_. So the script domain, the Console global and (for VWO) the cookie prefix together name the tool. Seeing any one is a strong signal; combining them is conclusive.

Can I tell which experiment variation I am seeing?

Sometimes, but not reliably from the outside. The tools store a variation identifier in a cookie or in their global object, so you can occasionally read which bucket you were assigned. But you cannot see the full experiment design, the other variations, the traffic split or the success metric — those live in the tool's dashboard. So detection reliably tells you a site runs experiments and which tool it uses, while the specifics of any given test stay private.

Is Google Optimize still something I will find?

Only as a leftover. Google Optimize was Google's free A/B testing tool, but Google shut it down in September 2023. A site may still carry a stale Optimize snippet or a googleoptimize.com reference in old code, but it is no longer running live experiments. So if you spot Optimize, read it as a legacy integration that has not been cleaned up, and look for a current tool like Optimizely, VWO, AB Tasty or Convert if the site is actively testing.

How to Tell if a Site Uses an A/B Testing Tool

To tell if a website uses an A/B testing tool, open the DevTools Network tab and reload, then watch which experimentation domains load: cdn.optimizely.com means Optimizely, dev.visualwebsiteoptimizer.com means VWO, and AB Tasty and Convert each fetch from their own recognisable domains. Confirm it in the Console by checking for the tool's global object — window.optimizely, window._vwo_code — and look for the tell-tale anti-flicker snippet near the top of the <head>. This works because client-side A/B tools must load early and announce themselves to swap content before the visitor sees it. This guide covers every signal, the major tools, and what detection can and cannot tell you about the experiments themselves.

It is a focused companion to how to find out what technology a website uses and pairs naturally with how to find out what analytics a website uses, since experimentation and measurement sit side by side in a growth stack.

What an A/B testing tool is, and why it is detectable

An A/B testing (or experimentation) tool lets a team show different versions of a page to different visitors and measure which performs better — a headline, a button colour, a layout, a whole flow. The dominant approach for marketing pages is client-side testing: a JavaScript snippet loads in the browser, decides which variation the visitor should see, and rewrites the page accordingly before (or just after) it renders. That mechanism is exactly what makes these tools detectable. To swap content without an ugly flash of the original, the snippet has to load early and synchronously, fetch its code from the vendor's servers, set a cookie to keep the visitor in a consistent bucket, and expose a JavaScript object to coordinate everything. Each of those steps leaves a fingerprint a browser can read. (Server-side experimentation, where the variation is chosen on the server, is far harder to see from outside — more on that limit later.)

Signal 1: the loaded script and its domain

The clearest fingerprint is the script the tool loads. Open DevTools (F12), go to the Network tab, and reload. Experimentation tools fetch their code from a recognisable domain:

Optimizely loads from cdn.optimizely.com (you will often see a project-specific path).
VWO (Visual Website Optimizer) loads from dev.visualwebsiteoptimizer.com.
AB Tasty loads from try.abtasty.com and its CDN.
Convert loads from cdn-3.convertexperiments.com (and related Convert domains).

Because these scripts usually load high in the page to minimise flicker, they appear near the top of the Network waterfall. Seeing one of these domains is close to conclusive on its own — they are not domains other categories of tool use.

Signal 2: the JavaScript global in the Console

Every client-side tool exposes a global object so it can coordinate variations and integrations, and you can check for it directly. Open the Console in DevTools and type the relevant test:

typeof window.optimizely returning "object" indicates Optimizely; you can type window.optimizely to inspect it.
window._vwo_code or window.VWO indicates VWO.
window.ABTasty indicates AB Tasty.
A convert or _conv_* global indicates Convert.

This Console check is a fast, reliable confirmation that complements the Network view — if the script loaded and initialised, its object will be present. It also distinguishes a genuinely active tool from a stray reference, because the object only exists when the snippet actually ran.

Signal 3: the anti-flicker (anti-flash) snippet

This is the signal that often gives the game away even before you know the vendor. Synchronous client-side tests risk a flash of original content — the visitor briefly sees version A before the script swaps in version B. To prevent that, tools install a small anti-flicker (or "anti-flash") snippet high in the <head>: an inline script plus a style rule that hides the page (commonly by setting the body to opacity: 0 or visibility: hidden) and then reveals it once the experiment code has loaded, or after a short timeout as a safety net. In View Source you will see a compact inline block near the top that hides and then un-hides the document. Spotting that hide-then-reveal pattern is a strong sign a synchronous A/B tool is present — and the surrounding code or a nearby comment usually names which one.

Signal 4: cookies and storage

Experimentation tools must remember which variation a visitor was assigned so the experience stays consistent across page views, and they do that with cookies or local storage. Open the Application tab in DevTools, look under Cookies and Local Storage, and read the keys:

VWO sets cookies beginning with _vwo (such as _vwo_uuid, _vwo_uuid_v2) and _vis_opt_*.
Optimizely stores visitor and bucketing data (historically in an optimizelyEndUserId cookie and in local storage).
Other tools set their own visitor or variation identifiers.

These persistence keys are a durable signal: even if you arrive after the script has finished its work, the stored identifier remains, naming the tool that set it.

The signal table

Tool	Script domain	Console global	Cookie / storage tell
Optimizely	`cdn.optimizely.com`	`window.optimizely`	`optimizelyEndUserId`, local storage
VWO	`dev.visualwebsiteoptimizer.com`	`window._vwo_code`, `VWO`	`_vwo_uuid`, `_vis_opt_*`
AB Tasty	`try.abtasty.com` / AB Tasty CDN	`window.ABTasty`	AB Tasty visitor cookie
Convert	`cdn-3.convertexperiments.com`	`convert` / `_conv_*`	`_conv_v`, `_conv_s`
Google Optimize (defunct)	`googleoptimize.com` reference	legacy `gaoptimize` hooks	stale only — shut down Sept 2023

A single matching row is usually enough; the script domain plus the Console global make it conclusive.

Method 1: View Source

The quickest single check is View Source. Open the page, press Ctrl/Cmd + U, and search for the vendor domains (optimizely, visualwebsiteoptimizer, abtasty, convert) and for the anti-flicker pattern at the top of the <head>. Because the experimentation snippet and its anti-flicker guard are placed directly in the server-rendered HTML — they have to load before content renders — they appear in the raw source before any other script runs. That makes a static source view a fast and effective first pass, and it is the same approach that anchors broader technology detection.

Method 2: the DevTools Network and Console

For a live, definitive read, combine the Network and Console tabs. In Network, reload and watch for the vendor script domain near the top of the waterfall; the request confirms the tool is genuinely loading on this page rather than merely referenced. In Console, run the typeof window.optimizely style check to confirm the global initialised. Together they tell you not just that the code is present but that it actually ran. If you want to see what other measurement loads alongside the experimentation tool — because A/B tests almost always feed an analytics platform — the same Network view supports how to find out what analytics a website uses.

Method 3: the Application tab for cookies

To confirm via persistence, open the Application tab and inspect Cookies and Local Storage for the keys in the table — a _vwo_uuid cookie names VWO directly, for instance. This method is especially useful when a tool loads asynchronously or when you arrive mid-session, because the stored visitor identifier sticks around after the script has done its work. Reading these keys is the same Application-tab discipline used to inspect any client-side storage, and it cross-references neatly with how to read a website's HTTP response headers, where Set-Cookie shows the server side of the same picture.

The Google Optimize footnote

For years, Google Optimize was the most common A/B testing tool on the web because it was free and integrated tightly with Google Analytics. That changed: Google shut Optimize down in September 2023. So if you find a googleoptimize.com reference or an Optimize snippet today, read it as a stale, legacy integration rather than a live experiment — the code may linger in a site's source long after it stopped doing anything. When you see Optimize, treat it as a sign the site once ran tests and check for a current replacement (Optimizely, VWO, AB Tasty, Convert, or a server-side framework) to find what, if anything, is running now. Calling out defunct tooling honestly is part of an accurate read.

A worked example

You want to know whether a competitor runs experiments. You open View Source and immediately notice a compact inline block at the very top of the <head> that sets the body to opacity: 0 and then restores it after a script loads — a textbook anti-flicker snippet. Searching the source, you find a reference to dev.visualwebsiteoptimizer.com. You open the Console and type window._vwo_code, which returns a function, and window.VWO, which returns an object — VWO confirmed. To be thorough, you open the Application tab and see a _vwo_uuid cookie and a _vis_opt_test_cookie. Every signal lines up: this site runs VWO for client-side experimentation, with the anti-flicker guard in place to avoid content flash. In a minute you have learned the tool, confirmed it is active, and inferred that the team takes conversion optimisation seriously enough to manage flicker.

What detection can and cannot see

Be precise about the limits. Detection reliably tells you which tool a site uses and that it is running client-side experiments, because the script, global and cookies are all observable. What it does not reveal is the content of any experiment: the variations being tested, the traffic split, the targeting rules, the success metric, or the results. Those live inside the tool's dashboard, which is private. You can sometimes read your own assigned variation from a cookie or the global object, but that is one data point, not the experiment design. And server-side experimentation — where the server decides the variation and sends only the chosen HTML — is largely invisible from the front end, because there is no client snippet to find; you might infer it only from subtle response differences. So report the tool with confidence, and treat anything about specific tests as private unless the site itself exposes it.

Why detecting an A/B tool matters

Knowing a site runs experimentation is a meaningful signal. For competitive research, it tells you a rival actively optimises rather than shipping and forgetting — and the specific tool hints at budget and maturity (an enterprise Optimizely deployment implies a different operation from a lean setup). For sales, especially if you sell conversion, analytics or experimentation software, the incumbent tool identifies both a competitor relationship and a possible switching opportunity. For technographic qualification, the presence of an A/B tool alongside analytics and a tag manager paints a picture of a data-driven team. And for performance review, synchronous experimentation snippets and their anti-flicker guards add load-blocking weight, which is worth weighing against the value they provide — a consideration covered in how to make your website load faster.

How accurate is A/B tool detection?

Accurate for client-side tools, limited for server-side ones. The script domains, Console globals and cookies are intrinsic to how client-side experimentation works, so naming the tool is reliable across the major vendors, and the anti-flicker snippet is a strong corroborating tell. The two honest gaps are server-side testing, which leaves little or no client trace, and the content of experiments, which is private by design. There is also the stale-snippet caveat — a leftover Google Optimize reference is not a live test. So "which client-side A/B tool does this site use?" is usually answerable with confidence, while "what exactly are they testing, and do they also test server-side?" often is not. Confirm the tool, note whether it is active, and be clear about what stays behind the dashboard.

The workflow

View Source and look for the anti-flicker snippet and vendor domains at the top of the <head>.
Open the Network tab and reload; watch for cdn.optimizely.com, dev.visualwebsiteoptimizer.com and friends.
Check the Console for window.optimizely, window._vwo_code and similar globals.
Inspect the Application tab for _vwo_* and other variation cookies.
Report the tool confidently; treat experiment specifics and server-side tests as out of view.

Go deeper

The whole stack: how to find out what technology a website uses.
The measurement beside it: how to find out what analytics a website uses.
The tag layer that often loads it: how to check if a website uses Google Tag Manager.
The performance cost of front-end scripts: how to make your website load faster.

Want a site's experimentation, analytics and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.

How to Tell if a Website Uses an A/B Testing Tool