When people think about adblock extensions, they usually imagine something simple:

“The extension sees an ad and hides it.”

That is only part of the story.

Tools like uBlock Origin are better understood as content blockers, not just ad blockers.

They do block ads, but they also block:

  • trackers
  • popups
  • malware domains
  • anti-blocker scripts
  • other unwanted page behavior

Modern blockers such as uBlock Origin mostly work by applying rules to:

  • network requests
  • page elements
  • scripts and browser behavior

So an adblock extension is not really “understanding ads” like a human would. Most of the time it is doing fast pattern matching:

  • Does this request URL match a blocked domain?
  • Is this script coming from a known tracker?
  • Does this page element match a CSS selector from a filter list?
  • Is there an exception rule that should allow it?

Once that mental model clicks, writing and debugging custom filters becomes much easier.

What an Adblock Extension Actually Does

Most adblock extensions work in three layers:

  1. Network filtering
  2. Cosmetic filtering
  3. Behavior fixes or scriptlets

Each layer solves a different problem.

1. Network Filtering

This is the most important part.

Every page loads many resources:

  • HTML
  • JavaScript
  • CSS
  • images
  • fonts
  • XHR or fetch calls
  • media files like audio and video

The blocker checks those requests against rules. If a rule matches, the request can be blocked before the resource fully loads.

That is why network filtering is so powerful:

  • it can stop ads before they render
  • it can block trackers before they send data
  • it can prevent heavy media or scripts from loading

Typical filter syntax looks like this:

||doubleclick.net^
||example.com/ads/^
||tracker.example^$script
||cdn.example.com^$image,domain=example.com

The ideas are simple:

  • ||domain^ usually means “match requests to this domain”
  • $script, $image, $media restrict the resource type
  • domain=example.com restricts where the rule applies

So the extension is not guessing. It is matching rules against URLs, types, and context.

2. Cosmetic Filtering

Sometimes a request is not blocked, but the element is still hidden from the page.

That is cosmetic filtering.

For example, an adblocker may inject CSS rules like:

example.com##.sponsored-banner
example.com##[aria-label="Advertisement"]

These do not stop the network request. They just hide matching page elements after the page loads.

That matters because some things are easier to hide than to block. A site may load the page from the same domain as its ads, which makes network-level blocking risky. In those cases, cosmetic filters are often safer.

3. Behavior Fixes and Scriptlets

Some blockers go one step further and inject small scripts or behavioral overrides.

This is useful for cases like:

  • anti-adblock popups
  • autoplay behavior
  • tracking functions
  • pages that keep retrying blocked requests

This is more advanced than simple URL blocking, but it is still rule-driven.

Where the Rules Come From

Most people do not manually write hundreds of filters.

Instead, extensions subscribe to filter lists such as:

  • uBlock filters
  • EasyList
  • EasyPrivacy
  • Peter Lowe’s list
  • malware or badware lists
  • regional lists
  • annoyance lists
  • custom user filters

A filter list is basically a maintained rule database. The extension downloads it, compiles it, and applies it while you browse.

That is why adblockers improve over time without you changing anything manually.

In uBlock Origin, the Filter lists pane is where you enable or disable these lists.

uBlock Origin also uses the EasyList filter syntax, and then extends it with extra syntax for more advanced filtering.

How We Usually Customize uBlock Origin

If you want to change behavior in uBlock Origin, there are a few common places to do it.

1. Filter Lists

If a site is breaking, sometimes the issue is not your custom rule. Sometimes a list you enabled is too aggressive.

So the first place to check is:

  • which lists are enabled
  • whether you added extra regional or annoyance lists
  • whether one of those lists is causing breakage

More lists do not automatically mean better blocking. More lists can also mean more breakage.

2. My Filters

This is where you add your own static filters.

For example:

||video.twimg.com^

or:

x.com##.some-promoted-container

This is the right place for custom network rules and cosmetic rules.

One important caution here:

Do not paste random filters from untrusted sources just because somebody posted them in a comment or a gist. Custom filters can break sites badly, and some trusted-only filters are powerful enough that they should not be copied casually.

3. Element Picker

If the thing you want to remove is visual, the element picker is often the easiest option.

It can create a site-specific cosmetic filter for you and save it into My filters.

That is usually safer than guessing CSS selectors by hand.

4. The Logger

If you are not sure what got blocked, open the logger.

This is one of the most useful parts of uBlock Origin because it shows:

  • the request URL
  • the resource type
  • whether it was blocked
  • which rule matched

That is the fastest way to understand why a site feature stopped working.

What Happens When We Block video.twimg.com

This part becomes easy once we think in terms of network requests.

When we open x.com, not everything loads from x.com itself.

Sites usually split things across different domains:

  • the main page may come from one host
  • images may come from another host
  • JavaScript may come from a CDN
  • videos may come from a separate media host

On X, videos are commonly loaded from video.twimg.com.

So when we add a rule like:

||video.twimg.com^

the extension blocks requests to that host.

That means:

  • ads using that host get blocked
  • but normal video files from that host also get blocked

So the page still opens, but the videos do not load.

That is why this rule feels like it is blocking ads, but it also ends up blocking normal video playback.

The Important Lesson: Host-Level Blocking Is Blunt

Blocking an entire host is often effective, but it is also the least precise approach.

If a domain is used only for ads or tracking, blocking the whole thing is fine.

If a domain is used for core site features, then blocking it can break:

  • login flows
  • comments
  • embedded media
  • images
  • infinite scroll
  • API calls

video.twimg.com falls into that second category. It is used for actual video delivery too.

How to Customize Adblock Behavior More Safely

If you want to customize a blocker, the safest approach is to make rules as narrow as possible.

1. Start Narrow, Not Broad

Bad first rule:

||video.twimg.com^

This blocks everything from that host.

A better rule is one that restricts:

  • resource type
  • page domain
  • specific path when possible

For example:

||example-cdn.com/ads/^$script,domain=example.com

That is much safer than blocking the whole CDN.

2. Scope Rules by Resource Type

Most blockers let you target only certain request types.

Examples:

||example.com^$image
||example.com^$media
||example.com^$script

This matters because the same host may serve different kinds of files.

If your goal is only to stop media, $media is safer than a blanket host rule. But in the video.twimg.com case, even $media would still block the normal videos you may want to watch.

So narrowing the type helps, but it does not solve the core problem if the site uses that host for normal playback.

3. Scope Rules by Site

You can also make a rule apply only on certain pages or sites.

Example:

||example-tracker.com^$domain=example.com

That means:

  • block this host
  • but only when the page you are visiting is example.com

This is useful when the same third-party host appears across many sites, but you only want to block it in one place.

4. Use Exception Filters to Undo Broad Static Blocking

Most blockers support exception filters starting with @@.

For example, if you blocked video.twimg.com broadly and want to allow it again on X, an allow rule can look like:

@@||video.twimg.com^$domain=x.com,media

The exact behavior depends on the extension and the rest of your rule set, but the general idea is:

  • allow requests to video.twimg.com
  • when they are media requests
  • while browsing x.com

This is often the fastest way to recover from an over-broad custom filter.

If you are using uBlock Origin’s advanced popup and dynamic filtering, be careful with green allow rules there. Those rules can override static filters very broadly.

For unbreaking a site during testing, a noop rule is often safer than a broad dynamic allow rule.

5. Prefer Cosmetic Filters When You Only Want to Hide Something

If your real goal is:

  • hide a promoted label
  • remove a sidebar module
  • collapse a sponsored card

then network blocking may be the wrong tool.

Cosmetic filtering is often safer because it changes presentation, not core resource loading.

That is especially true on modern web apps where first-party and third-party resources are mixed together.

6. Use the Extension Logger Before Writing Permanent Rules

Most serious blockers have a logger or request inspector.

Use it.

It tells you:

  • which URLs were requested
  • which rules matched
  • which requests were blocked
  • which site triggered the request
  • what resource type was involved

If you had opened the logger while loading a video on X, you would likely have seen requests to video.twimg.com getting blocked, which immediately explains why the video is not loading.

That is much better than guessing.

In practice, the logger should come before permanent custom rules.

First inspect.

Then block.

Then test.

Can You Block Ads on X Without Breaking All Video?

Sometimes yes, but not always cleanly at the network level.

That depends on whether X separates:

  • promoted video assets
  • regular user video assets
  • tracking and measurement endpoints

If both promoted and normal videos are delivered through the same media host and similar paths, then a host-level rule cannot reliably distinguish them.

That is the key limitation of URL-based blocking:

If two kinds of content come from the same place, a simple network rule may not be able to separate them.

In that situation, better options are often:

  • a cosmetic rule that hides promoted containers
  • a site-specific rule that targets ad UI rather than media delivery
  • turning off autoplay instead of blocking the video host

A Good Mental Model for Custom Rules

When you create a custom adblock rule, ask:

  1. Am I blocking a full host or a specific path?
  2. Does this host serve only ads, or also real content?
  3. Should this apply everywhere or only on one site?
  4. Should this apply to all resource types or only one?
  5. Would a cosmetic filter be safer than a network filter?

Those five questions prevent a lot of self-inflicted breakage.

Final Takeaway

Adblock extensions mostly work by matching requests, elements, and behaviors against rule sets.

That is why they are both powerful and easy to misconfigure.

If you are using uBlock Origin, the practical places to customize behavior are usually:

  • Filter lists
  • My filters
  • Element picker
  • Logger

When we block:

||video.twimg.com^

it blocks the ads using that host, but it also blocks the actual video files.

So videos on X stop working too.

The practical lesson is simple:

  • use the narrowest rule you can
  • prefer site-scoped and type-scoped filters
  • use exception rules when a block is too broad
  • use cosmetic filters when you only want to hide UI

That gives you much more control without accidentally breaking half the site.