How-to · Developer
How to block unwanted redirects with a redirect blocker Chrome extension
The short answer
Add a rule with the Block action and a URL pattern matching the redirect target — or the script that triggers it — and matching requests are cancelled in the browser before they leave. The hit log and badge count show every request the rule stopped, so you can verify the blocker actually worked.
- 1
Open the extension and add a rule with the Block action.
- 2
Use the Record tab to capture the page's traffic and find the redirect target or the script that triggers it.
- 3
Enter a URL pattern for it (e.g. ||redirector.example.com^), or enable Regex for rotating hosts.
- 4
Save and reload — matching requests are now cancelled in the browser.
- 5
Confirm the block in the hit log and toolbar badge, then group the rule by project or environment.
A page keeps bouncing you somewhere you didn't ask to go — a forced mobile-site redirect, a tracking hop sitting between a link and its real destination, or a third-party script that navigates the tab on its own. A rule-based redirect blocker takes a different approach from an ad blocker: instead of a curated filter list, you name exactly which requests to cancel, and it shows you proof every time it does. That precision is what makes it useful when you want to prevent a redirect while developing without breaking everything else on the page.
Add a block rule
Open the extension and create a rule with the Block action. Give it a name you'll recognize later — "kill mobile redirect" or "no analytics on staging" beats "rule 7".
Find what to block
If you don't know which request starts the redirect, use the Record tab first: it captures the page's real traffic locally, so you can spot the redirector domain — or the script that kicks off the chain — and turn that request straight into a rule.
Match it with a pattern
Enter a URL pattern such as ||redirector.example.com^, or switch on Regex if the chain rotates hostnames. Matching requests are cancelled inside the browser — nothing is proxied through a server.
Verify it in the hit log
Reload the page. The toolbar badge counts hits and the hit log lists exactly which requests were blocked and when. That matters because a cancelled request is easy to miss in a busy DevTools timeline — the log is your proof of effect.
Scope it per project
Group your block rules by environment — one set for staging, one for a client project — and toggle a whole group on or off in one click instead of hand-editing rules.
What it can and can't block
Two honest limits. First, out of the box on Chrome the extension intercepts fetch/XHR traffic; blocking top-level page navigations, service-worker or WebSocket requests needs Full Mode, which Chrome flags with a "debugging this browser" banner while it's on (Firefox has no such blind spots). Second, a rule blocker stops the requests you've named — it is not an antivirus and won't recognize scam redirects it has never been told about.
Everything runs locally: rules live on your device, there's no telemetry, and block rules are unlimited in the free tier.
