Chrome Declarative Net Request Rules: 5 Hard Limits (2026)

You open a video, a sponsor card slides in, and the next site shows an ad network you have not seen before. A declarative net request rule is one of Chrome’s Manifest V3 instructions, subject to 5 hard quotas, that matches a request and can block, redirect, or modify it before the page receives the resource.

A small rule list leaves two leaks open. A new ad domain appears after your blocklist was last refreshed. A new site sends a tracker through a path your rules never anchored. Both losses repeat every time the browser meets that domain or site.

Key takeaways

• A DNR rule has an id, priority, an action, and a condition.
• Chrome evaluates at most one candidate rule per extension for each request.
• Five browser quotas shape what an MV3 blocker can ship, from static rulesets to regex rules.

What a DNR rule is

Structured answer: A declarative net request (DNR) rule is a Manifest V3 object with an id, priority, action, and condition. Chrome matches incoming requests against enabled rules, resolves ties by priority and action order, and applies the winning action. The rule format is based on the filter-list syntax common to most ad blockers. A rule’s action can block, redirect, modify headers, upgrade the scheme, allow, or allow all requests.

Fields carry the decision. action says what to do: block, redirect, modifyHeaders, upgradeScheme, allow, or allowAllRequests. condition says when to apply it, using urlFilter or regexFilter, resourceTypes, initiatorDomains, and related fields. priority breaks ties when two rules match the same request. The id lets an extension update or remove the rule later.

MV3 changed the blocking model. MV2’s webRequest namespace exposed nine potentially blocking events, and each event could take an unlimited number of handlers. Chrome replaced that callback path with declarative rules. To block a request, an extension needs the declarativeNetRequest permission. That permission asks for no host permission. The redirect and modifyHeaders actions need declarativeNetRequestWithHostAccess plus a host permission.

How Chrome evaluates the rule set

Chrome does not run a per-request callback for DNR. For each request, it looks at every installed extension that holds the permission. Each extension can contribute at most one candidate rule for that request. If several rules from the same extension match, Chrome first uses the highest priority. If priority is equal, the action order decides the winner: allow and allowAllRequests beat block, block beats upgradeScheme, and upgradeScheme beats redirect.

Across extensions, the order changes. A block action from one extension wins over a redirect or upgradeScheme from another, and those win over an allow action.

The 5 hard limits

The limits below are the ones that shape a shipped blocker. They come from Chrome’s DNR API reference.

A safe dynamic rule uses one of the safe actions: block, allow, allowAllRequests, or upgradeScheme. Unsafe dynamic rules cover the remaining actions. The available static rule count is not fixed per user. It depends on every installed extension. Chrome 128+ stopped counting disabled extensions toward the global static rule quota. An extension can check the live number with getAvailableStaticRuleCount().

URL patterns that decide what a rule matches

A DNR rule only does what its pattern allows. urlFilter uses simple pattern anchors. ||example.com/ anchors the domain and matches its paths. |https://example.com/ also anchors the protocol. Wildcards such as * and ^ widen or bound the match. A regex rule uses regexFilter instead.

One trap is a bare domain string. A filter written as example.com can match a page whose query parameter contains that string. If the rule is meant to block a domain and its subdomains, anchor the whole domain. For a path, keep the leading slash. A rule that is too loose blocks useful resources. A rule that is too narrow misses the ad network it was written for.

Rule count as a coverage signal

Rule count is a coverage signal. More bundled URL patterns mean a wider set of ad and tracker requests can be matched before the page loads. A blocker that ships far fewer rules leaves more room for a new domain to leak through.

SuperchargePerformance bundles 195,000+ DNR rules across 15 static ruleset files. Its tiered setup includes low, medium, and pro blocklist tiers, script tiers, font tiers, image_block, and yt_ad rulesets. The extension’s manifest marks the low blocklist and script_low as enabled by default. Other tiers switch on at runtime through chrome.declarativeNetRequest.updateEnabledRulesets. The runtime also verifies that Chrome indexed the enabled rulesets. It uses getAvailableStaticRuleCount() and retry passes because Chrome deferred indexing can silently delay or fail rule activation. The live Chrome Web Store build is 1.5.0 as of October 2026.

If ads return on a site after a new network appears, check rule coverage before switching blockers. A tiered setup lets you switch to a larger rule set on demand. For more on MV3 blocker behavior, see Chrome ad blockers for Manifest V3.