> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/lookup-privacy/ad-and-tracker-blocking-test.md).

# Ad & Tracker Blocking Test

See what your ad or tracker blocker actually stops — an extension, your browser's own protection, or a DNS, VPN or router filter — and where the blocking happens.

## What it does

You installed an ad blocker, switched on your browser's tracking protection, or pointed your devices at a filtering DNS service, VPN or router. The **Ad & Tracker Blocking Test** shows what that setup really lets through.

It works in three ways:

* **Requests.** Your browser contacts well-known ad, analytics, social and device-maker addresses, and the tool notes which ones never got out.
* **Scripts.** It fetches the exact URLs of popular tracking scripts — the files sites load to run a tag or a pixel. They are downloaded, never run.
* **Element hiding.** It places a few invisible bait elements shaped like ad slots on the page and watches whether a blocker hides them.

It is a public tool: no sign-in, no quota, and it works on self-hosted copies too.

## How to run it

Go to **Advanced Tools → Network Diagnostics** and click the **Ad & Tracker Blocking Test** card (the 🛡️ card), or open `/tools/adblocktest` directly. From the dashboard, the keyboard shortcut is <kbd>x</kbd>.

Nothing runs when the page opens.

1. **Choose what to test.** The list on the left — above the results on a phone — holds every category, and all of them start selected. Tick or untick a category's heading to switch the whole category, or single services underneath it. **Select all** and **Invert** sit at the top, next to the number of checks selected.
2. **Press Start test.** A progress line counts the checks as they answer. The selection is locked until the run ends.
3. **Stay on the page until it finishes.** If you leave mid-run, the element-hiding check is left without an answer.

## The categories

| Category                           | What is in it                                                                                                                                               |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ad networks**                    | Ad servers and ad exchanges — Google Ads, DoubleClick, Amazon Ads, Criteo, Taboola and others — checked by domain.                                          |
| **Analytics & session recording**  | Visitor statistics, heatmap and session-replay services such as Google Analytics, Microsoft Clarity, Hotjar and Mixpanel.                                   |
| **Social network trackers**        | Pixels and conversion trackers run by social platforms — Meta, X, LinkedIn, TikTok and others.                                                              |
| **Error & performance monitoring** | Crash reporting and real-user monitoring services such as Sentry, Bugsnag and Datadog.                                                                      |
| **Device maker telemetry**         | Telemetry and ad addresses used by phone, TV and device makers. Your browser never calls these on its own, so mainly DNS, VPN and router filters list them. |
| **Tracking scripts**               | Exact URLs of popular tag and pixel scripts. Filters that match by path can catch these even where the domain itself is allowed.                            |
| **Element hiding**                 | Bait elements shaped like ad slots. Only a blocker inside the browser can hide them.                                                                        |

## Reading your results

### The summary

Four tiles open the results:

* **Blocked share** — the percentage of answered requests that were blocked.
* **Blocked** — the request never left your device, or was refused on the way.
* **Not blocked** — something answered. The request got through.
* **No answer** — the request stalled until it timed out. That proves neither a block nor a pass, so it does not count towards the blocked share.

Element hiding is not part of these numbers. A DNS, VPN or router filter can never hide an element on a page, so counting it would mark those setups down for something they were never meant to do.

{% hint style="info" %}
**A higher score is not automatically better.** Not every tracker works against you. Error reporting helps sites fix crashes, analytics helps them improve, and ads pay for much of the free web. Some device-maker addresses also deliver updates or notifications, so blocking them can have side effects. Read the result as a map of what your setup lets through, and decide for yourself what is worth blocking.
{% endhint %}

### Where the blocking happens

Below the tiles, one line says where your blocking most likely sits:

| What you see                                 | What it means                                                                                                                                                   |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bait elements were hidden                    | A blocker is working inside your browser — an extension, or the browser's own.                                                                                  |
| Requests were blocked, baits were not hidden | The blocking happens outside the page: at a DNS service, VPN or router, or in the browser's tracking protection, which blocks requests without hiding elements. |
| Nothing was blocked                          | No ad or tracker blocking was found in this browser or on this network.                                                                                         |

This line needs both halves of the test. Without **Element hiding** in the run it does not appear; with element hiding alone, it appears only when a bait was hidden.

### Category by category

Each category you tested gets its own block, with its blocked count, such as `12 / 40 blocked`. Inside it, one card per service shows how many of its addresses were blocked, not blocked, or gave no answer. Click a card to list every address it tried, each with its own mark. For element hiding, each bait reads **Hidden** or **Visible** instead.

The filter tags at the top — **All**, **Not blocked only** and **Blocked only** — narrow the view to one outcome, with every card already expanded. **Not blocked only** is the quickest way to see what got past your blocker.

At the bottom, **Test list version** shows which version of the address list you ran. The list is updated over time, so two runs on different versions may not be directly comparable.

## Privacy

* **Requests that are not blocked do reach those services.** That is the only way to find out whether they get through. The tool sends them without cookies and without a referrer: the service sees your IP address, as with any request, but not the page you came from, and nothing that ties the request to an account.
* **Scripts are fetched, never run.** Nothing a tracking script contains executes on your device.
* **Results stay in your browser.** They are not sent to IPCheck.ing. If you put them in a [diagnostic report](/knowledge-base/getting-started/sharing-a-diagnostic-report.md), only counts per category go in.

## Honest limits

* **Blocked means "did not get through", not "stopped by your blocker".** An address your network cannot reach for any other reason — a firewall, a network-wide block, an outage at the service — shows as blocked too. If one service stands out, check it with the [Connectivity Check](/knowledge-base/connection-tools/connectivity-check.md) or [DNS Resolution](/knowledge-base/lookup-privacy/dns-resolver.md).
* **The tool only learns whether something answered.** Browsers do not let a page read another site's reply, so a reply of any kind — even an error — counts as not blocked.
* **A probe is not how a website loads things.** Each check is a plain request sent by the tool's page. A filter rule aimed only at one request type — scripts or images, say — can let the probe through and still block the real script or ad on a website, so **Not blocked** is not proof your blocker would miss it. The results page notes this under the test list version.
* **Your results depend on this browser.** An extension only protects the browser it is installed in, and a filter on your home router does nothing on mobile data. Run the test in each browser and on each network you care about.
* **It is a sample, not a full audit.** The list covers widely used services, not every tracker on the web. A blocker that passes here can still miss something elsewhere, and the reverse.

## Related pages

* [Browser Fingerprint](/knowledge-base/lookup-privacy/browser-fingerprint.md) — what your browser reveals even when trackers are blocked
* [Browser Fingerprinting Explained](/knowledge-base/concepts/browser-fingerprinting.md) — tracking that needs no cookies at all
* [How DNS Works](/knowledge-base/concepts/how-dns-works.md) — the layer DNS-based filters work on
* [Security Checklist](/knowledge-base/lookup-privacy/security-checklist.md) — the wider picture across your digital life
* [Sharing a Diagnostic Report](/knowledge-base/getting-started/sharing-a-diagnostic-report.md) — bundle these counts with your other results


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ipcheck.ing/knowledge-base/lookup-privacy/ad-and-tracker-blocking-test.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.