Ad Blockers That Still Work in Chrome: 4 Ways to Block Ads

Chrome didn't kill ad blocking. It killed one specific technical approach, and took a popular extension's full functionality down with it. If ads have started slipping through since your last Chrome update, or an old uBlock Origin install stopped filtering the way it used to, the good news is that ad blockers that still work in Chrome are easy to find, once you know which one actually matches your problem.

Before the technical explanation, a quick decision rule:

• Want the simplest fix without leaving Chrome? Install an MV3-native blocker.
• Rely on custom filter rules or maximum blocking power? Move to Firefox.
• Want ad blocking on devices and apps a browser extension can't touch? Use DNS-level filtering.
• Want the strongest coverage overall? Layer a Chrome extension with DNS filtering.

The four sections below walk through each option: who it's for, how to set it up, and where its limits sit.

Why your Chrome ad blocker stopped working

Manifest V3, Chrome's current extension platform, replaced the real-time webRequest blocking API with declarativeNetRequest (DNR). The old API let extensions inspect and block network requests live, in JavaScript, as a page loaded. DNR instead requires extensions to declare their filtering rules in advance and hand the matching over to the browser itself, according to Palancar's migration guide. Chrome still lets extensions observe requests; only the blocking and modifying variant disappeared for most extension categories, and that's precisely the capability the full version of uBlock Origin depended on, Mozilla has explained.

The rollout itself is messier than a single cutoff date. Google started disabling Manifest V2 extensions in Chrome Stable in October 2024, after warnings first appeared in the beta, dev, and canary channels, per the Chromium blog. Enterprise deployments running a specific exemption policy kept MV2 access through June 2025. New extensions and updates submitted to the Chrome Web Store have needed to be MV3-compliant for a while now, per Palancar, which is a separate question from whether an extension you already installed still runs.

That last point matters, because Chrome's own developer documentation, updated earlier this month, still frames the transition as unfinished. It describes extensions as being able to "continue to use Manifest V2 for now," with a phase-out planned "in the near future" rather than a date already behind us, per Chrome's developer docs. That's a softer, more open-ended timeline than the specific version-number cutoffs circulating elsewhere. If your own extensions are still working, don't assume that's an accident, and don't assume it's permanent either. Open chrome://extensions and check directly rather than trust a date printed in an article, this one included.

None of that architecture change is a verdict on whether ad blocking still works, though. Researchers at Goethe University Frankfurt tested MV2 and MV3 versions of four major blockers, Adblock Plus, AdGuard, Stands, and uBlock Origin, in their default configurations, and found no statistically significant drop in blocking performance. MV3 builds actually caught an average of 1.8 more tracking scripts per site in one measurement, per a PoPETs 2026 study summarized by Extenshi. That's a meaningful data point against the assumption that MV3 blockers are inherently worse, though it covers default setups rather than heavily customized filter lists.

How to block ads in Chrome after Manifest V3

The options below run from simplest to most thorough. Start with the first unless you already know you need something more specific.

1. Install an MV3-native blocker

This is the right starting point for most people: no browser switch, no router access, no upkeep beyond letting the extension update itself.

1. Open the Chrome Web Store and search for uBlock Origin Lite or AdGuard.
2. Click Add to Chrome and approve the requested permissions.
3. Pin the extension's icon to the toolbar so you can see it running.
4. Reload a page you know carries ads or trackers and check the icon for a blocked-request counter.

If the counter stays at zero after a reload, the extension probably hasn't been granted site access yet. Open its options page and confirm it can run on all sites, or at least the ones giving you trouble.

These two extensions consistently show up as the serious MV3-native options for Chromium browsers, in Extenshi's comparison of what's currently available. Google's own 2024 update named MV3 versions of AdBlock, Adblock Plus, uBlock Origin, and AdGuard as available, and noted that over 85% of actively maintained Chrome Web Store extensions had already moved to Manifest V3 by that point.

Don't confuse uBlock Origin Lite with the full uBlock Origin. Lite is built around DNR rather than the blocking version of webRequest, the API the original extension relied on and that Chrome no longer permits for blocking decisions, as Palancar's guide explains. It's a separate build designed around that constraint, not a patched version of the same tool, so expect less customization even though the core blocking still works.

On raw effectiveness, the same testing described above found MV3 builds of these blockers held up in default configurations. That's the reason uBlock Origin Lite and AdGuard keep coming up as viable, not just convenient.

What no extension in this category fixes: ads served from the same domain as the page content defeat URL-pattern filtering no matter which API is doing the matching, Extenshi notes. In-feed native ads and similar formats will keep getting through.

2. Switch to Firefox for full uBlock Origin

Firefox is the fix for a narrower complaint: not "I'm seeing more ads" but "my custom filters stopped working" or "I need to block based on what's inside a request, not just its address." Firefox kept the blocking version of webRequest under its own Manifest V3 implementation, something Chrome removed, according to Mozilla. That matters because DNR can match a request's URL, but it cannot inspect a request's contents and decide based on what's inside, per Palancar's guide, which is exactly the capability advanced filter lists and privacy tools depend on. If you've never touched a custom filter list, this distinction probably doesn't affect you. If you have, it's the whole reason to switch.

1. Download and install Firefox.
2. Import bookmarks using Firefox's built-in import tool. If a separate password manager already handles your logins, nothing changes there; if Chrome's built-in password storage was doing the job, use the importer for that too.
3. Install the full uBlock Origin from the Firefox Add-ons store.
4. Bring over custom filter lists and test them rather than assuming they behave identically. Firefox's rule limits and supported conditions aren't identical to Chrome's, so imported rulesets need verification, per Palancar.

To confirm it's working, open uBlock Origin's logger while browsing a site that trips your custom rules and watch for matches in real time.

The honest cost is the switch itself: re-establishing sync, rebuilding a bookmark setup, adjusting to a different browser's habits. For readers running heavily customized filter lists or privacy tools that need to inspect requests rather than just match their addresses, that cost is worth paying. For everyone else, it probably isn't.

3. Add DNS-level filtering

This section is a map, not a script. DNS filtering works underneath the browser entirely, which is why it complements extension-based blocking rather than replacing it, but the exact menus differ by device, operating system, and provider. Treat what follows as the general shape of the setup, not a walkthrough for one specific service.

There are two distinct ways to configure it, and they cover different ground:

Device-level (one phone or laptop): open that device's network settings, find the DNS server field for the active connection, replace it with the addresses from whichever DNS filtering provider you've chosen, save, and reconnect so the change takes effect.

Router-level (every device on the home network): log into the router's admin page, usually reached through an address printed on the router itself, find the WAN or DHCP/DNS settings, swap in the provider's DNS addresses, save, and reboot the router.

The catch that breaks this setup most often: Chrome and other modern browsers often default to their own DNS-over-HTTPS settings, which can bypass DNS rules configured at the router level entirely, per Blockify. Fix it by opening Chrome's Privacy and Security settings, finding "Use secure DNS," and either turning it off or pointing it at the same provider set up at the router. On a managed work or school Chromebook, that setting may be greyed out entirely; the device's administrator controls it, not you, and router-level filtering won't reach that browser's traffic regardless of what you change locally.

To check whether filtering is actually working, visit a domain your provider is known to block and confirm the connection fails or redirects, rather than assuming success just because nothing looked different. If a legitimate site breaks afterward, the fix is almost always to whitelist that specific domain through the provider's dashboard, not to turn filtering off altogether.

Two limits are worth knowing going in. DNS filtering blocks a domain before the page ever loads, which means it can't do cosmetic cleanup, so a blank space where a blocked ad used to sit may still show up in the layout. And because it works by blocking domains rather than reading page content, it runs into the same wall as browser-based filtering when an ad is served from the same domain as the content around it.

4. Layer a Chrome extension with DNS filtering

This combines the two Chrome-side options above. Running an MV3-native extension alongside DNS-level filtering covers more device and browser contexts than either method alone: the extension handles in-page and cosmetic filtering inside Chrome, DNS filtering reaches other devices and apps on the same network that a browser extension never sees.

There's a quiet performance benefit to the extension side of this pairing, too. DNR matches rules in Chrome's native code instead of routing every request through the extension's JavaScript, which lowers the per-request cost and means the extension's background worker doesn't need to stay alive to keep servicing traffic, per Extenshi's explanation.

Here's the judgment call, stated plainly: an MV3-native extension by itself is enough for typical single-device browsing in Chrome. "Typical" excludes households running multiple devices on the same network, ad-supported mobile apps, and streaming boxes or smart TVs, none of which a Chrome extension can touch. If any of those apply, the DNS layer is doing real work. If none do, it's optional overhead.

Which setup fits your situation

The comparison below summarizes the trade-offs described above rather than introducing new rankings; there's no single "best" answer, because the right setup depends on whether the problem lives inside Chrome or outside it. For readers specifically hunting for the best ad blockers for Chrome as a standalone question, the first row is the answer. The rest of the table is for problems a Chrome extension structurally can't solve.

What to do next

None of this is settled for good. Google's own documentation still describes the Manifest V2 phase-out as ongoing rather than finished, per Chrome's developer docs, rule limits and permission models keep shifting from one Chrome release to the next, and enterprise policies can run on a different clock than a personal install.

Pick a setup from the four above based on what's actually broken for you, not on principle. Then check chrome://extensions every few months rather than assume a working blocker keeps working on its own. A warning banner next to an old extension is the signal to act on now, not a detail to skim past later.