Free tool

Filter Rule Generator

Build blocking, hiding and exception rules from a form, with live syntax validation. Output works unchanged in uBlock Origin, AdGuard and Adblock Plus.

Build a rule
Limit to resource types (optional)
uBlock Origin · AdGuard · Adblock Plus
||doubleclick.net^
Cancels every request to this domain before it is sent. All three engines accept this rule unchanged, because they share the EasyList syntax core.
Where to paste this
uBlock OriginDashboard → My filters
AdGuardSettings → Filters → User rules
Adblock PlusSettings → Advanced → My filter list

The four rules that cover almost everything

Filter syntax has a large surface area, but ordinary use needs very little of it. Almost every rule people actually write falls into one of four shapes, which is why this generator offers exactly those four rather than exposing every option in the specification.

GoalShapeEffect
Block a domain||ads.example.com^The request is never sent
Hide an elementsite.com##.ad-bannerElement removed, request still happens
Make an exception@@||example.com^Overrides blocking rules for this domain
Allow a whole site@@||site.com^$documentDisables all filtering on that site

Reading the syntax

The || prefix anchors a match to the beginning of a domain name and automatically includes every subdomain, so ||example.com^ also covers ads.example.com and track.example.com. Without it, the pattern would match anywhere in a URL and produce accidental matches on unrelated sites.

The trailing ^ is a separator placeholder. It matches any character that is not a letter, digit, or one of _ - . %, and it also matches the end of the address. It exists so that ||example.com^ does not accidentally match example.com.attacker.net.

Everything after $ is an option list that narrows the rule. The most useful are third-party, which applies the rule only when the request comes from a different site than the one you are visiting, and domain=, which restricts the rule to specific sites.

Writing rules that do not break sites

The most common mistake is writing a rule that is broader than intended. Blocking a domain that serves both advertising and an essential asset, such as a payment widget or a login script, will break the page in a way that is hard to trace back weeks later. Scope aggressively: prefer domain= to limit the blast radius, and prefer blocking a specific subdomain over a whole registrable domain.

For cosmetic rules, avoid selectors built on generated class names. Modern build tools produce class names like .css-1x3fp2q that change on every deployment, so a rule written against one will silently stop working. Target a stable container, an ARIA role or a data attribute instead.

Where these rules go

In uBlock Origin, open the dashboard and use the My filters tab. In AdGuard, go to Settings, then Filters, then User rules. In Adblock Plus, use Settings, Advanced, and the custom filter list. Rules take effect immediately in all three; no restart is needed.

If your goal is simply to stop filtering on one site rather than to write a rule, whitelisting through the extension interface is simpler and less error-prone. And if rules that used to work have stopped, check your filter lists are updating before rewriting anything.

Frequently asked questions

How do I block a specific domain in uBlock Origin?

Use a rule of the form ||example.com^ and paste it into Dashboard, My filters. The double pipe anchors the match to the start of a domain including all its subdomains, and the caret matches a separator such as a slash, colon or the end of the address.

What is the difference between ## and ||?

The double pipe starts a network rule, which cancels a request before it is sent. The double hash starts a cosmetic rule, which hides an element that has already loaded. Network rules save bandwidth and stop tracking; cosmetic rules only tidy the page.

Do uBlock Origin and AdGuard use the same filter syntax?

For ordinary blocking and hiding rules, yes. Both build on the EasyList syntax that Adblock Plus established, so the rules this tool generates work unchanged in all three. They diverge only in advanced extensions such as scriptlet injection and HTML filtering, which use engine-specific syntax.

Why is my cosmetic rule not working?

The two usual causes are an unscoped rule that the engine rejected as too broad, and a selector that matches an element added after the cosmetic pass ran. Scope the rule to a domain, and prefer matching a stable parent container over a generated class name that changes on every deploy.

How do I stop a rule breaking a site?

Write an exception. A rule beginning with @@ overrides any blocking rule that would otherwise match, so @@||example.com^$document disables filtering for that site entirely while leaving your other rules intact.

Related