ERR_BLOCKED_BY_CLIENT: Ad Blockers, Extensions and How to Fix It

ERR_BLOCKED_BY_CLIENT (shown as net::ERR_BLOCKED_BY_CLIENT) means a request was cancelled inside the browser before it left the computer. An extension, a built-in shield or a browser policy decided the request should not happen. The most common source is an ad or tracker blocker. It is available in Chromium browsers (Chrome, Edge, Brave, Opera); Firefox blocks silently and reports a generic network failure in the console, usually NS_ERROR_BLOCKED_BY_POLICY or a failed network request.

The server is not involved: it never sees the request, so there is nothing in your access logs and your uptime monitor will not show a problem. You usually see it in two places: as a full-page error when a blocked URL is the main page, and, far more often, as a red entry in the DevTools Console or Network tab for a script, image, iframe or API call on a page that otherwise looks fine.

If you are a visitor

1. Check which extensions are active. Open the extensions menu and look for ad blockers, privacy tools, antivirus browser add-ons, parental controls and script blockers.
2. Test in an incognito window with extensions disabled (extensions are off by default there unless you allow them). If the page works, an extension is responsible.
3. Pause the blocker on that site. Most blockers have a per-site toggle. Add the site to the allow list only if you trust it.
4. Check browser built-ins. Brave Shields, Edge Tracking Prevention and similar features block requests without any extension. Look at the shield or padlock icon in the address bar.
5. Review managed policies. At chrome://policy, an organization may block URLs with URLBlocklist. If so, only your administrator can change it.
6. Check DNS-level and network filtering only if the error looks different. Network-level blocks normally appear as connection errors, not as ERR_BLOCKED_BY_CLIENT.
7. If checkout or login fails, an overzealous blocker may stop a payment or captcha script. Disable the extension for that page and retry.

If you own the site

When customers say a button, form, chat widget or payment step does nothing, reproduce it with an ad blocker on and check the console. Real examples include analytics, tag managers, social widgets and anything hosted at a domain that appears on a filter list.

1. Find exactly which requests are blocked

Open DevTools, then the Network tab, and filter for "blocked" or look for red rows with status (blocked:other) or (failed) net::ERR_BLOCKED_BY_CLIENT. Note the URL. Then check whether it came from your own domain or a third party. The Third-Party Script Checker lists external scripts your page loads, so you can see what is exposed to blockers.

2. Rename first-party paths that look like ads or tracking

Filter lists match patterns in URLs. Paths and filenames containing words such as ad, ads, banner, sponsor, promo, track, analytics, pixel or affiliate are sometimes blocked even when they serve legitimate content. Typical cases:

• An image at /images/ads/spring-sale.jpg or /banner-300x250.png.
• An internal API like /api/ads/list or /api/tracking/orders that powers real functionality.
• A script called ads.js that actually runs your product carousel.

Rename to neutral names (/images/offers/spring-sale.jpg, /api/campaigns/list) and update references. This fixes your own features without touching anyone's blocker.

3. Make critical functions not depend on blockable resources

Treat third-party scripts as optional:

• Load analytics, chat and tag-manager scripts asynchronously and wrap calls in checks such as if (window.gtag) gtag(...).
• Do not let a blocked script prevent form submission; the form should work without any tracker.
• For payment and login, prefer your own domain for essential API calls, and use the payment provider's documented integration, which blockers generally leave alone.
• Provide a visible fallback message when an embed fails to load, such as "This content is blocked by your browser settings."

4. Do not try to defeat blockers

Anti-adblock scripts and constantly changing URLs create a poor experience and an arms race. Fix mistakenly blocked first-party resources, and accept that optional third-party features may be unavailable for some visitors.

5. Do not confuse it with CORS or CSP failures

These look similar in the console but differ. A CORS failure says "blocked by CORS policy" and is fixed on the server; see CORS: no Access-Control-Allow-Origin header and the CORS Checker. A CSP violation says "Refused to load... violates the Content Security Policy" and is fixed in your headers; read the CSP guide. Frame problems say refused to display in a frame. Only ERR_BLOCKED_BY_CLIENT indicates a client-side blocker.

6. Test with real blockers

Before launching a campaign or checkout redesign, test with a popular blocker enabled and with Brave's default shields. It takes minutes and catches the problem before customers do. Include a pass through the Website Health Check to find unrelated problems at the same time.

Confirm the fix

1. Reload with the blocker enabled and confirm the Network tab shows no blocked first-party requests.
2. Check the headers of the renamed resources with the HTTP Header Checker.
3. Re-run the Third-Party Script Checker to review what remains exposed.
4. If the page uses a critical API endpoint, include it in an API monitor.

Next steps

• Review third-party performance with the Third-Party Script Checker.
• Read about content security policy.
• Learn about mixed content if resources are failing for another reason.
• If a request fails because of a proxy, see ERR_TUNNEL_CONNECTION_FAILED.

FAQ

Is ERR_BLOCKED_BY_CLIENT a server error?

No. The request never reached the server, so there is nothing to fix in its configuration. The cause is in the visitor's browser.

Why does it only happen for some of my visitors?

Only users with a blocker or a strict privacy setting that matches your URL pattern will see it. Others load the same resource normally.

Can I detect it from the server?

Not directly, because no request arrives. You can detect failed loads in client-side code, for example by checking whether a script's global object exists.

Does it affect SEO?

Search crawlers do not run ad blockers, so it normally does not. But if important content depends on a script that blockers stop, some users will not see it.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.