Ways to block ads, compared honestly

Ad blocking sounds like a solved problem until you try to pick a method and realize there are at least five different layers where blocking can happen, each with different tradeoffs. None of them catches everything, and most guides skip the part where they explain why. Here’s ad blocking compared at the level of how each method actually works, so you can pick a combination that fits your setup instead of installing whatever a forum thread told you to.

What “ad blocking” actually covers

There isn’t one thing called ad blocking. There are at least three separate jobs: stopping the request for an ad from ever going out, stopping the ad from rendering once it arrives, and stopping the tracking script that rides along with it. Different tools handle different combinations of these jobs, and that’s the main reason comparisons that just rank tools by a single “best” list are misleading. A method that’s excellent at stopping requests can be useless at stopping visual clutter, and vice versa.

Browser extensions: filtering inside the browser

Extensions like uBlock Origin work inside the browser’s rendering and network pipeline. They do two things. First, network-level filtering: before a request for a known ad-serving URL goes out, the extension checks it against filter lists (EasyList and similar) and blocks the request outright. Second, cosmetic filtering: even for content that does load, CSS rules hide the empty containers and layout elements associated with ads, so you don’t get blank boxes where ads used to be.

This is the most granular method available, because the extension can see the actual page structure and match against constantly updated lists maintained by volunteers and researchers. The tradeoff is scope: it only protects the browser it’s installed in. Your phone’s native apps, your smart TV, other browsers on the same machine, and other devices on your network are untouched. It also depends entirely on filter list quality and update frequency, since a list that goes stale stops catching new ad domains.

DNS-level blocking: filtering before the connection

DNS blockers, whether that’s a self-hosted Pi-hole on your network or a hosted resolver like NextDNS, work a layer below the browser. When any device on the network tries to resolve a domain (say, an ad network’s tracking subdomain), the DNS server checks it against a blocklist and returns nothing, or an unreachable address, instead of the real IP. The device never even establishes a connection to the ad server.

The strength here is coverage: because DNS resolution happens for every device that uses that resolver, a single Pi-hole or NextDNS configuration can protect a smart TV, a game console, and every phone on the same Wi-Fi, none of which support browser extensions. The weakness is precision. DNS blocking is domain-level, all or nothing. It can’t do cosmetic cleanup, so a blocked ad often leaves a blank space rather than a reflowed page. It also can’t distinguish between an ad and legitimate content served from the same domain, which matters more than people expect: some ad networks use CNAME cloaking, routing ad traffic through a subdomain of the site you’re actually visiting, specifically to blend in with first-party DNS traffic and dodge exactly this kind of blocklist.

Built-in browser blocking: convenience over configurability

Some browsers ship blocking natively. Brave has its own filtering engine built in, and Safari uses a content blocking API where blocklists get compiled into an efficient rule set the browser applies before pages render. These work at roughly the same layer as extensions, matching and blocking network requests, but they’re set up out of the box with no extension install required.

The tradeoff is control. Built-in blockers usually offer fewer configuration options than something like uBlock Origin, and you’re relying on the browser vendor’s choice of filter lists and update cadence rather than picking your own. For most people that’s a reasonable default. For anyone who wants to add custom filter lists, whitelist specific sites element by element, or inspect exactly what’s being blocked and why, a dedicated extension gives more visibility into what’s actually happening.

VPN and app-based network filtering

Some VPN services and dedicated apps advertise ad blocking as a feature. Technically, these usually work one of two ways: either the VPN provider runs its own DNS resolver with a blocklist applied (the same mechanism as Pi-hole, just hosted for you), or the app runs a local VPN interface on your device purely to intercept and filter traffic without actually routing it anywhere external.

The DNS-based version has the same strengths and limits as any DNS blocker: broad coverage, no cosmetic filtering, and it can be defeated by cloaking techniques. It adds one more consideration worth naming plainly: your DNS queries, meaning a list of every domain your devices try to reach, pass through that provider’s resolver. That’s true of any DNS blocker, including a self-hosted one, but it’s worth being aware of who operates the resolver you’ve pointed your devices at, since that’s a meaningful amount of information about your browsing regardless of how it’s used. This isn’t a claim that any particular VPN or ad-blocking app is trustworthy or not, just a reminder to know what data flows through a service before adopting it as your default resolver.

The hosts file: the old school method

The hosts file is a plain text file on your device that maps domain names to IP addresses, and it’s checked before your device even makes a DNS query. Adding known ad-serving domains to it, pointed at 0.0.0.0 or 127.0.0.1, blocks them the same way DNS blocking does, just locally and per device instead of network wide.

It costs nothing, needs no extra software, and works across every browser and app on that device at once. But it’s manual: you have to find, download, and periodically update a hosts file list yourself, there’s no automatic refresh, and like DNS blocking it can’t do cosmetic filtering or catch cloaked first-party ad traffic. It’s a solid option for a single device you don’t mind maintaining, and a poor fit if you want something that updates itself.

What none of these fully solve

Worth saying directly: none of these methods is complete, and stacking several of them narrows the gaps rather than closing them entirely. Anti-adblock scripts on some sites detect when network requests are being blocked and respond by nagging you or refusing to load content until you disable the blocker, an arms race that plays out between filter list maintainers and publishers. First-party ads, meaning ads served directly from the site’s own domain rather than a third-party ad network, dodge both extension network filtering and DNS blocking unless a filter list specifically targets that pattern. And blocking ads is a separate job from blocking tracking; some trackers don’t serve visible ads at all, so a tool optimized purely for visual ad removal may leave tracking scripts untouched, and a tool optimized for tracker blocking may still let some ads through.

Picking a combination that matches your setup

The practical takeaway from comparing these honestly is that they’re not really competitors, they operate at different layers and solve different parts of the problem. A DNS blocker at the network level plus a browser extension on your main machine covers more ground than either alone, because the DNS layer catches devices the extension can’t reach, and the extension’s cosmetic filtering cleans up what the DNS layer leaves as blank space. The hosts file is a reasonable single-device fallback if you’d rather not run network infrastructure. What matters is knowing which layer each tool operates at, so you’re not surprised when a “complete” ad blocking setup still lets something through, because it was never designed to catch that particular thing in the first place.

If you want more breakdowns like this that explain how privacy and security tools actually work instead of just ranking them, check out the rest of The Privacy Wire.