Free tool
DNS Blocking Test
Checks whether ad and tracker domains are being stopped before your browser sees them, and uses request timing to infer whether the blocking is happening at the network or in the browser.
Timing each request to infer where blocking happens…
How network blocking differs from browser blocking
A DNS filter sits between your device and the internet. When any device on your network asks
where doubleclick.net lives, the filter answers with nothing, or with an address
that goes nowhere. The connection never happens. This covers phones, tablets, consoles and smart
televisions, none of which can run a browser extension.
The trade-off is granularity. DNS operates on whole domains and nothing finer. It cannot block a single tracking script while allowing the rest of a domain, it cannot hide an empty advertisement container left behind on the page, and it is powerless against tracking served from the site's own domain. Those are exactly the cases a browser extension handles well.
Reading the timing column
The right-hand column shows how long each failed request took. This is the only signal a browser has about where the block happened, because the browser is never told the reason a connection failed.
| Result | Typical cause |
|---|---|
| Under 25ms | A browser extension cancelling the request in-process |
| 25ms to timeout | A DNS resolver refusing the query, or returning an unroutable address |
| Timeout | A resolver silently dropping the query, which some Pi-hole configurations do |
| loaded | Nothing blocked it at any layer |
Isolating your DNS filter
The cleanest way to test network-level blocking on its own is to remove the other variable. Disable every ad blocking extension in this browser, reload, and run the test again. Whatever is still blocked is being stopped upstream of the browser entirely. If the score collapses to zero, your device is not actually using the filtered resolver, which is usually a DHCP configuration issue rather than a Pi-hole problem.
Choosing between the options
We compare the common setups in detail in NextDNS versus Pi-hole and pfBlockerNG versus Pi-hole. The short version: NextDNS requires no hardware and follows you between networks, Pi-hole gives you complete local control and no third party sees your queries, and pfBlockerNG makes sense if you already run pfSense.
Whichever you run, a browser-level blocker still covers the gaps DNS cannot reach. Run the full ad blocker test to see the combined result.
Frequently asked questions
How do I test if my Pi-hole is working?
Disable any ad blocking browser extension, then run the test above. Anything still reported as blocked is being stopped before your browser, which means your Pi-hole is filtering correctly. If everything loads with extensions off, your device is not using the Pi-hole as its resolver.
Why does the test say extension rather than network?
Because of timing. A browser extension cancels a request inside the browser, so it fails in a few milliseconds. A DNS filter has to reach a resolver that refuses or drops the query, which takes noticeably longer. Consistently fast failures point at an extension doing the work.
Is DNS blocking better than a browser extension?
They solve different problems. DNS blocking covers every device on the network including smart TVs and phones, but it cannot hide page elements, cannot block anything served from a first-party domain, and cannot filter by resource type. An extension can do all three but only inside that one browser. Running both is common.
Why can this not tell me exactly which layer blocked a request?
A browser is not told why a request failed. It only sees that the connection did not succeed. Everything beyond that is inference from timing, which is why this tool reports a likely layer rather than a definitive one.