Ad blockers and content blockers: what they really change

A blocker is a filter between a web page and your browser. It checks every request the page tries to make against lists of patterns, and cancels the ones that match. That is the whole mechanism, and two consequences follow that people rarely separate. Blocking an ad is not the same as blocking the tracking attached to it. And a blocker can only act on the part of the system it can see, which is smaller than most users assume. Which kind you install decides which of those you get.

How a blocker decides what to block

The intelligence is not in the software, it is in the filter lists. A list is a text file of rules, each one a pattern describing a request: a domain, a path fragment, sometimes a resource type such as script or image, and often a condition that it only applies when the request goes to a different domain than the page. Volunteers and small teams maintain the main lists and publish updates frequently, because the domains being blocked change constantly.

When a page loads, the blocker is handed each outgoing request before it leaves your machine. If a rule matches, the request is cancelled and the browser gets nothing back. Because there is also a syntax for exceptions, a list can say block this everywhere except on that site, which is how maintainers repair breakage without weakening the rule.

The side effect people notice first is speed. Blocked requests are never downloaded, never parsed and never executed, so pages that were carrying a dozen third party scripts load faster and use less data. That is a real gain on a thin connection, though it is not a fix for a line that is genuinely slow.

Network blocking versus cosmetic hiding

Blockers do two different things and the difference explains most of what confuses people.

A network rule stops a request. Nothing is fetched, so nothing arrives, and you save the bandwidth. A cosmetic rule is a style instruction applied after the page has loaded, hiding an element that matches a selector: the empty frame a blocked ad left behind, a newsletter overlay, a promoted item in a feed. The content was still downloaded. The blocker simply refuses to show it to you.

Cosmetic rules are written per site and they are brittle. When a site renames its internal class names, which large platforms do routinely, the rule stops matching and the thing reappears until a maintainer updates the list.

This is also why ads on big social and video platforms are harder to remove than a banner on a news site. A banner comes from a separate ad domain, so it can be blocked outright. A platform ad is served from the same domain and often through the same pipe as the posts you asked for, so blocking the request would break the feed. Hiding is the only lever left, and it is a losing race by design.

Blocking ads and blocking tracking are different jobs

Most people install a blocker to remove clutter and assume privacy comes free. It partly does, but the two are handled by different lists. Ad lists target the domains that deliver ads. Privacy lists target measurement and analytics domains, which often serve nothing visible at all. Most blockers enable some of each by default, and the exact mix is a setting worth opening once.

Then there is the part no blocker reaches. When a site collects an event itself and its own server forwards it to a measurement company, your browser only ever talks to the site you chose to visit. There is no third party request to cancel. That approach is now common, and it is the main reason a blocker is a useful layer rather than a solution, as the full picture of how tracking is actually assembled shows.

One more gap: lists that hide consent banners make the banner disappear without answering it. That is a cosmetic fix to a legal mechanism, and it is not the same as refusing consent, which matters if you care about what reject all is supposed to do. Some blockers also ship an allowance that permits ads meeting a set of conditions. It is usually disclosed and usually switchable, so check rather than assume.

Extension, DNS filter or built in protection

The second row deserves attention because it is oversold. Filtering at the DNS layer is genuinely useful: it covers the television, the console and the phone apps that no extension can reach, and it is one setting for the whole house. But it only ever sees a domain name, so it works at the resolution of whole domains. It cannot block one ad on a site while allowing the rest, and when it does break something, the failure appears weeks later with no obvious cause. The mechanics and its bypasses are covered in how DNS decides where you land. A blocker of this kind also does nothing about ads injected by software already on your machine, which is a different problem with a different fix.

What breaks, and why

Breakage clusters in predictable places. Sign in buttons that use another company as the identity provider. Comment sections, chat widgets and embedded forms. Video players that call a measurement script before starting. Maps. Checkout pages that load a payment provider in a frame. In each case the blocked request was doing a job the page depends on, not just delivering an ad.

The diagnosis is always the same: disable the blocker for that site, reload, and see. If the page works, add an exception for that site and move on. If it does not, the blocker was not the problem.

Separately, some sites detect a blocker and refuse to show content until it is turned off. Lists chase those detectors and the detectors change again, so expect the arms race rather than a permanent win. A site is entitled to decline to serve you, and deciding what to do about that is a judgement call rather than a technical one.

The trust problem nobody mentions

To filter requests, an extension needs permission to read and change data on every site you visit. That is the strongest permission a browser hands out, and it is exactly the permission a hostile extension would want. Popular blockers have been sold to new owners before and quietly turned into data collection tools, with the blocking still working perfectly so nobody noticed.

So judge the project, not the feature list. Prefer one that is open source with a public repository, that has a long and visible update history, that is maintained by a named project rather than an anonymous publisher, and that does not bundle coupon or shopping features. Install one, not three: they conflict, they do not stack usefully, and each extra one is another program reading every page you open. The wider version of this reasoning is in what a browser extension can actually do.

The setup worth doing today

1. Install one well maintained content blocker in the browser you use most, and leave the default lists alone at first. The defaults are tuned to break as little as possible.
2. Leave your browser own tracking protection switched on. It works at a different layer and the two complement each other rather than duplicating work.
3. Open the blocker settings once. Check whether an allowance for certain ads is on, decide whether you want it, and confirm the lists are updating automatically.
4. Use per site exceptions when something breaks. A blocker that is globally paused because of one checkout page three months ago is doing nothing for you.
5. If televisions, consoles or phone apps bother you, add DNS filtering at the router as a second layer, and expect to keep an allowlist for the things it breaks.
6. On a phone, install a browser content blocker and accept that apps are outside its reach. A filtering VPN style app can cover them, at the cost of routing everything you do through that company.

Set your expectations honestly. This removes most ads, a large share of third party tracking, and a surprising amount of page weight. It does not remove measurement the site gathers itself, and it does nothing about the account you are signed into while you read.