Block a request - Loupewire guides

A block pattern stops matching requests from being sent at all. The usual reasons: proving that a page really depends on the endpoint you think it does, or simulating a third-party outage you cannot arrange for real — an analytics host that is down, a payment provider that stops answering.

This is the only one of the four pattern lists whose effect leaves the tracker page. Track and Skip decide what is recorded, Mask decides what is drawn; Block changes what your browser actually does.

Before you use it, read Patterns: one rule, four places — matching works the same way, with one exception this page covers.

Add a pattern

Open the Block list in the toolbar and type a substring of the URLs you want stopped: doubleclick.net, /v2/reports, analytics.example.com.

The note under the input is the whole feature in two sentences: "These requests are never sent. Blocking stops when this window closes, and a pattern broad enough to match a page will stop that page from loading."

The Block popover with analytics.example.com typed and added as a chip, the Block count reading 1, and the note about blocking under the input — One pattern, in force from the moment it is added.

Block is the one list that refuses characters. Your pattern becomes a rule for the browser's own rule engine, and *, ^ and | mean something to that engine — a rule written with them would match URLs you never described, silently. They are refused, along with non-ASCII text, which the browser rejects outright. The guide on patterns has the details and the way around the second one.

A blocked request still appears

This is the part people do not expect. A blocked request is exactly the one you want to look at, so it gets a row: method, URL, resource type, and a BLOCKED marker in the status column.

The request table with one row reading BLOCKED in purple, for the URL matching the pattern, among ordinary rows with 200 and 404 statuses — Stopped, and still on the record. BLOCKED is purple rather than red: nothing failed, the product did what it was told.

Open it and the tabs do not all say the same thing, because they cannot:

Headers and Cookies are empty, and say why: the request was stopped before any header was sent. They do not claim the request "had no cookies" — nobody knows what it would have carried.
The Body tab still works. The browser reports a request body before the rule stops the request, so a blocked POST still shows what it was about to send. That is often the reason you blocked it.
Meta names who blocked it, and puts the browser's own error string underneath rather than replacing it. It also carries the duration, which for a blocked request is a fraction of a millisecond — itself evidence that nothing went to the network.

The detail panel of a blocked request: the Headers tab reading Stopped before any header was sent — Empty because nothing was sent, and it says so rather than claiming there were no cookies.

The Meta tab of the same request: Blocked by reading One of your block patterns, Error reading net colon colon ERR_BLOCKED_BY_CLIENT, and a duration of 0.196 milliseconds — The verdict, the browser's own words under it, and a duration of 0.196 ms.

Who blocked it

BLOCKED does not always mean you. The browser reports the same error for any extension's blocking rule, so with an ad blocker installed most blocked rows are somebody else's. The tracker asks, once, at the moment of the block, whether one of your patterns matched — and the row keeps that answer for good.

That means the attribution never changes when you edit your pattern list afterwards. A row says what was true when the block happened, which is the only thing evidence is allowed to do.

On Brave there is a third case, and it is invisible: Shields blocks below the level any extension can see, so a request Shields stopped produces no row at all. If traffic you expect is simply missing, check Shields before blaming the tracker.

Blocking lives and dies with the window

Close the tracker and every block pattern stops. Open it again and the patterns you kept come back into force.

This is deliberate and it is the safety property of the feature. The browser rule a pattern becomes would otherwise outlive the page that wrote it — and a rule left behind is invisible: no window open, nothing to inspect, and a site that simply does not load. Nobody connects that with an extension window they closed an hour ago. So the contract is simple: the tracker window is open, therefore blocking is in force.

Common mistakes

A pattern broad enough to match the page. example.com stops the document request too, and the tab shows an error page instead of your app. Name the narrowest thing you mean.
Expecting Block to quieten the table. It does the opposite — it adds rows, marked. If you want fewer rows, that is Skip or the filter.
Expecting it to apply everywhere, all the time. It applies while the tracker is open. That is the whole design, not a limitation waiting to be lifted.
Reading BLOCKED as "my pattern did this". Check the Meta tab. Another extension produces the same row.

Not in this version

Redirecting or rewriting a URL is deliberately not here — it is a different product from an inspector, and the roadmap says so rather than "later". Regular expressions and matching by method are planned. So is blocking by resource type rather than by URL.