webtracking.org
tools

Is Your Ad Blocker Actually Working? Test It Against 12 Real Trackers

Test whether your ad blocker actually blocks trackers: a free client-side tool that probes 12 real analytics, ad, social, and session-replay endpoints.

last verified 2026-07-18

Installing a content blocker and having a working content blocker are two different things. Filter lists go stale, extensions get silently disabled after browser updates, Firefox’s built-in protection behaves differently in private versus normal windows, and a single “allow on this site” click can exempt a whole profile. Most people have no way to verify any of this — the blocker’s icon looks the same whether it is blocking everything or nothing.

The Tracking-Prevention Tester answers the question directly: it attempts to fetch twelve well-known tracker resources from your browser and reports which ones your extensions, browser settings, or network layer actually stopped. It runs entirely client-side, transmits no results anywhere, and does nothing until you press the button.

It is useful from both directions. If you run a blocker, it verifies your stack. If you run a measurement program, it is a concrete way to see what an ad-blocking visitor’s browser does to your tags — the same cancelled requests that protect that user are the reason your GA4 numbers undercount.

What it does

The test matrix is twelve real tracker endpoints in four categories:

  • Analytics — Google Analytics (analytics.js), the Google tag loader (gtag.js), and Mixpanel’s library from cdn.mxpnl.com.
  • Advertising / ad servers — the Google Publisher Tag (gpt.js from securepubads.g.doubleclick.net), Google AdSense (adsbygoogle.js), and Amazon’s header-bidding tag (apstag.js).
  • Social media pixels — the Meta Pixel (fbevents.js), the X/Twitter universal website tag (uwt.js), the TikTok Pixel, and LinkedIn Insight.
  • Session replay — the Hotjar and FullStory loader scripts.

Each endpoint gets a live result pill — blocked, loaded, or no response — plus the time the request took. Per-category tallies (“2/3 blocked”) update as requests settle, and a headline score box shows how many of the twelve requests your stack stopped. A separate panel tests cosmetic filtering (the element-hiding half of a content blocker), and a closing panel names the categories where requests got through and points to the relevant hardening guides.

How it works

The engine is small and readable — it is inline in the page source, and the page invites you to view source to verify.

Request probing. Each endpoint is requested with fetch(url, {mode: "no-cors", cache: "no-store", credentials: "omit", referrerPolicy: "no-referrer"}) wrapped in an AbortController with a 4-second timeout. The classification logic is:

  • The fetch rejects → counted as blocked. Content blockers cancel matching requests, which surfaces to the page as a network error.
  • The fetch resolves → counted as loaded. In no-cors mode the response is opaque — the page cannot read it — but a completed response proves the tracker host was reachable.
  • The abort timer fires first → counted as timeout, displayed as “no response” with ”≥ 4000 ms”. Timeouts count toward the blocked total, with an on-page note that an overloaded network can look the same.

Requests carry no cookies and no referrer, and the page never executes any tracker code — it only observes whether each request completes. Timing comes from performance.now().

Scoring. The score is simply the count of non-loaded results out of twelve. The headline number is colored by the blocked ratio: 90% or better reads as good, 50–89% as middling, below 50% as poor.

Cosmetic filtering. Network blocking is only half of what a content blocker does; the other half is hiding ad-shaped elements. The tool inserts four bait <div>s off-screen using class names that common element-hiding filter lists match — adsbox, ad-banner, ad-placement, and a combined string of classic bait classes (pub_300x250 pub_728x90 text-ad textAd text_ad text_ads text-ads text-ad-links). After waiting for a rendered frame (a double requestAnimationFrame raced against a 300 ms fallback, since rAF can stall in background tabs) plus a 450 ms settle window for slower DOM-surveying blockers, it checks each bait’s computed style. Any element with offsetHeight === 0, display: none, or visibility: hidden counts as hidden, and the panel reports how many of the four baits an element-hiding stylesheet caught.

How to use it

  1. Open the Tracking-Prevention Tester in the browser and profile you want to test. Read the notice first: the test makes real network requests to known tracker domains, so any request your stack does not block will reach that tracker’s server as an ordinary resource request from your IP (without cookies or a referrer).
  2. Press “Run test — contact 12 tracker endpoints.” Nothing runs on page load; no request is made until you click.
  3. Watch the progress counter (“7/12 settled”) and the per-row pills flip from “testing…” to blocked, loaded, or no response, with per-request timings.
  4. Read the score box, the cosmetic-filtering panel, and the recommendations panel, which lists the categories where requests completed and links the guides for fixing them.
  5. Change something — enable a filter list, switch protection modes, turn on your DNS filter — and press “Run again” to compare.

Comparing runs across browsers and modes is the most instructive use: try a normal window versus a private window in Firefox, or the same browser with and without your VPN’s blocking enabled.

Limitations

The tool states its own caveats, and they matter for reading the results honestly:

  • A blocked request is indistinguishable from a network failure. Offline, behind a captive portal, or on a flaky connection, everything reads as blocked.
  • Opaque responses hide substitutions. A DNS filter that answers with a dummy server, or a blocker that swaps in a harmless local stub instead of cancelling the request, can read as “loaded” even though the real tracker was never reached or the script was disarmed.
  • Results are a moving target. Filter lists update constantly; the same browser can score differently next week depending on list subscriptions and configuration.
  • Browser modes matter. Firefox blocks known trackers in private windows by default but needs strict mode to do so in normal windows.
  • Cosmetic filtering often skips local pages. On file:// URLs, element hiding is usually off unless the extension has been granted file access.
  • Twelve endpoints is a sample, not the ecosystem. A 12/12 score is evidence your blocker works — not proof you are untrackable.

Everything runs in your browser: no analytics, no cookies, and no result collection on the page itself.

FAQ

Does running the test expose me to tracking? Only to the extent your stack fails. Requests are sent without cookies (credentials: "omit") and without a referrer, and no fetched code is ever executed — but if a request is not blocked, that tracker’s server sees an ordinary request from your IP address. That trade-off is the test.

What does “no response” mean? The request neither completed nor errored within the 4-second timeout. It counts as blocked in the score — some blocking techniques stall requests rather than cancel them — but a slow or overloaded network produces the same result.

I use Pi-hole or NextDNS and some rows still say “loaded.” Is my DNS blocking broken? Not necessarily. no-cors responses are opaque, so the page only observes that something answered. A DNS filter that responds with a dummy server can read as “loaded” even though the real tracker never saw the request. See DNS, VPN and network blocking for how to verify at that layer.

My blocker is on, but cosmetic filtering says “not detected.” Why? Element hiding may be disabled in your blocker’s settings, turned off for this page, or — if you opened the tool as a local file — not applied because the extension lacks file access. Network blocking and cosmetic filtering are independent features; passing one does not imply the other.

Is 12/12 the goal? For a hardened setup, yes — the tool treats 90%+ as a good score. But a perfect score only proves these twelve request-level blocks worked. Fingerprinting, first-party collection, and server-side tracking are separate problems.