ERR_BLOCKED_BY_CLIENT website error explained

What it means

net::ERR_BLOCKED_BY_CLIENT appears in the Chrome DevTools console or Network tab when a network request is cancelled before it ever reaches the server. The browser blocked it, not the server. The most common source is a browser extension such as an ad blocker or privacy tool that matches the request URL against a filter list and cancels it. A misconfigured Content Security Policy or CORS rule can produce a similar devtools message, but the extension case is far more common and is what this error name most often refers to.

This is not a connection failure. Your internet is working and the page the request belongs to is reachable; the specific asset (a script, image, or API call) was stopped client-side. Because an extension does the blocking before any connection is made, there is nothing a server log will show for it, and the server cannot do anything to prevent it directly.

Confirm the extension is the cause

The fast test is an incognito window. Extensions are disabled by default in incognito mode. Press Ctrl+Shift+N on Windows or Cmd+Shift+N on macOS, open the failing page there, and reopen the console. If ERR_BLOCKED_BY_CLIENT no longer appears, an extension is responsible. If the message persists in incognito, the cause is not an extension.

When an extension is the culprit, identify which one by disabling extensions one at a time. Open the extension manager, disable the ad blockers and privacy tools first (the most common offenders), reload the page after each toggle, and observe when the error clears. For a single offending extension, allowlisting the site or the exact blocked URL inside its settings is cleaner than turning the extension off entirely.

Stop the false positive

Site owners cannot fix a visitor's ad blocker, but they can stop naming resources in a way that trips community-maintained filter lists. Paths and file names containing terms like /ads, /track, /pixel, /banner, /sponsor, or /analytics are frequent false-positive triggers, so a legitimate asset such as analytics.example.com/track.js or an image at /assets/banner-promo/hero.png can be blocked purely because of its path.

If the blocked request is one you control, rename the file or directory to a neutral, functional name (for example, replace /js/promo-banner.js with /js/featurebox.js) so real filters stop matching it. Confirm the fix by opening the site in a normal window with the ad blocker active and checking the Network tab again. The goal is that essential scripts and core content load even for the largest proportion of visitors running ad blockers, which is the same principle the third-party script impact article applies to reducing reliance on fragile external scripts.

For a visitor, the resolution is theirs: if a page is missing content because of a blocked asset, allowlisting the site in the active blocker, or using the stopped request URL in the LCP position, fixes the immediate symptom. For a developer the deeper lesson is that a request that never reaches the server is invisible to your logs, so documenting which third-party resources your page depends on is the practical defence, the first rule of diagnosing why a page will not load.