RN
For most of the last decade this was a shopping question. You picked a blocker from a list, installed it, and that was the end of the matter.
It stopped working that way when browser vendors changed the rules underneath. The extension you are able to run is now largely determined by the browser you happen to use, because content blockers do not work by magic — they work through an API the browser provides, and the browser decides what that API is allowed to do. When the API changes, every blocker built on it changes with it, regardless of how good the blocker was.
So the honest version of this guide starts one level up.
Why the platform matters more than the product
A content blocker needs to inspect requests a page makes and decide, in the moment, whether to allow them. Historically the extension APIs let it do exactly that: the blocker saw each request and answered dynamically, using whatever logic its filter lists implied.
The newer generation of extension platform works differently. Instead of asking the extension about each request, the browser asks the extension to register a set of rules in advance and then applies those rules itself. The extension no longer sees the traffic.
The reasoning offered for this is performance and privacy — an extension that inspects every request is an extension that could log every request. The consequence, whatever you make of the reasoning, is that the declarative model is less capable than the dynamic one. Rulesets are finite where the old approach was open-ended. Filters that depended on context or on responding to what a page did are harder or impossible to express. Lists that update constantly against sites that change constantly are exactly the case the newer design handles worst.
None of this means blocking stopped working. It means the ceiling moved, and it moved differently in different browsers.
What this means when you go to install something
The practical shape of it, without naming versions that will be wrong by the time you read this:
Browsers built on the older, more permissive extension model retain the full-capability blockers. This has generally meant the Firefox family, which has kept support for the more powerful API alongside the newer one. If maximum blocking capability is what you are optimising for, that is the direction to look first.
Chromium-based browsers vary by vendor. Chromium is a shared base, but each vendor decides its own extension policy on top of it, and several have made different calls about how long to support what. Do not assume that two browsers behave the same because they share an engine.
Several established blockers now ship in two versions. A full one built on the older API and a lighter one built on the newer, with the lighter version deliberately more limited — fewer custom filters, less dynamic behaviour, less user control. The names are similar enough that people install the reduced version without realising it is the reduced version. Read which one you are getting.
The general rule to carry away: check the blocker's own project page for the current browser support position before you install anything. Not a listicle, not a store listing, not this article. The project pages are maintained by the people affected by the changes and they are blunt about what works where.
Why adult sites are the hard case
Ad blocking on a news site is close to solved. On large tube sites it is not, and the reasons are structural.
Pop-unders and redirect scripts. Rather than displaying a banner, the page opens something else, often triggered by the first click anywhere on the page — including on the play button. This is a behaviour rather than a resource, which makes it a different class of problem from blocking an image.
First-party ad serving. Advertising delivered from the same domain as the video does not have a distinguishing hostname to filter, which defeats the simplest and most robust blocking method.
Overlays inside the player. Ads composited into the video area are part of the playback path, and blocking them aggressively tends to break playback.
Anti-adblock detection. Many sites now detect a blocker and require you to disable it. Filter lists include countermeasures, the sites respond, and the countermeasures update again. This particular contest is the clearest illustration of why the capability ceiling matters: it is exactly the kind of dynamic, context-dependent filtering the newer extension model constrains.
The realistic expectation, then, is substantial improvement rather than a clean page. Anyone promising a completely ad-free experience on a large free tube is selling something.
Phones are a separate problem with a separate answer
Extensions are a desktop concept. On mobile the landscape is different enough that desktop advice transfers badly.
Some mobile browsers support extensions and some do not, and on the platforms where the browser engine is dictated by the operating system, content blocking happens through a system mechanism rather than through the browser. Both routes only cover the browser they are attached to — they do nothing for a page opened inside another app.
That gap is the reason to know about the network-level option.
DNS filtering: complementary, not a replacement
Rather than filtering inside the browser, you can point your device or router at a DNS resolver that refuses to resolve known ad and tracking domains. Self-hosted and hosted services both exist for this.
What it is good at: covering every app and every device on the network at once, including the ones where you cannot install anything, with no per-browser configuration.
What it cannot do: anything requiring knowledge of the page. It resolves hostnames, so it cannot remove an element, cannot touch anything served from the same domain as the content, and cannot respond to a script's behaviour. Blocking a hostname that a site depends on also produces a broken page rather than a cleaned one.
Run both if you care about this. They fail in different places, which is the entire argument for layering them.
The category is itself a risk
A content blocker sees every page you visit. That is the permission it requires to function, and it makes the extension itself a high-value position.
Blockers have been sold to new owners and quietly turned into data collection. Store listings mimicking well-known blockers exist and are frequently the top search result. "Free VPN and ad blocker" bundles are a recurring pattern that is worth a hard look before installing.
Three habits cover most of it. Install from the project's own page rather than from a search result. Prefer blockers that are open source and independently maintained, so a change of behaviour is visible to somebody. And treat a browser's extension permissions screen as a thing to read rather than a thing to click past — an extension you installed is the one attack surface you chose voluntarily.
Where this leaves you
Pick the browser first, because that decision sets the ceiling. Install one reputable blocker from its own project page, and check what that project currently says about your browser rather than assuming. Add DNS-level filtering if you want coverage across apps and devices. Then stop, because a second blocker layered on the first mostly produces conflicts and broken pages.
And keep the expectation calibrated. On the sites where this matters most, blocking is an ongoing contest rather than a settled state — which is why the specific recommendation matters less than knowing what determines it.