Blocking webRequest let an extension sit in the path of every request and decide what to do with it. The declarativeNetRequest API lets an extension hand Chrome a set of rules instead, so Chrome does the blocking and the extension does not have to view request content. That is a privacy gain, with trade-offs for what rules can express.
How the old approach worked
Google's Manifest V3 overview says the blocking version of webRequest required extensions to proxy all network traffic, which carried performance and privacy costs. An extension with that power could read and change requests as they passed through. Most did so for good reasons, like blocking trackers, but the power was there for any extension that asked.
How declarative rules work
With declarativeNetRequest, the extension supplies rules and the browser applies them. Google's reference describes three rule types:
- Static rules, packaged in JSON files in the extension and installed or updated with it.
- Dynamic rules, which persist across sessions and extension upgrades and are managed at runtime.
- Session rules, which are cleared when the browser shuts down or a new extension version is installed.
There are limits. Dynamic rules go up to 30,000, with up to 5,000 of those allowed to be "unsafe" ones, meaning anything other than block, allow, allowAllRequests or upgradeScheme. Session rules go up to 5,000. Enabled static rulesets are guaranteed at least 30,000 rules.
The permissions to look at
Three names matter when you read a manifest:
declarativeNetRequestshows an install-time warning and gives implicit access to block and allow actions.declarativeNetRequestWithHostAccessshows no install-time warning, but the extension must still hold host permissions for any site it acts on.declarativeNetRequestFeedbackis for debugging in unpacked extensions.
The second one deserves attention. A missing warning does not mean no access. Read the host permissions alongside it, as covered in our permission warnings guide.
What it does not do
Declarative rules limit what the blocking path can see. They do not stop an extension from also holding host permissions and content scripts that read pages. An ad blocker built on rules alone has a smaller footprint than one that also injects scripts into every site. When you review an extension, look at all of its capabilities together.
Common mistakes
A frequent error is judging an extension by one permission. Rule based blocking looks modest, yet the same package may hold content scripts on every site. Another is trusting a missing install warning. Read the full manifest, and compare the stated purpose with each capability.
Quick check
Does declarativeNetRequest let an extension read my requests?
Google describes it as letting extensions act on requests without intercepting them or viewing their content. Other permissions in the same extension may still give it other access.
Is blocking webRequest completely gone?
Google says it is deprecating the blocking version in Manifest V3. Check the current reference before relying on any exception, since details can change.
Sources
Last reviewed: 19 October 2026.
