ERR_BLOCKED_BY_CLIENT Error: What It Means and How to Fix It

What is the ERR BLOCKED BY CLIENT error and what should you do first?

ERR BLOCKED BY CLIENT, shown as ERR_BLOCKED_BY_CLIENT in the console, is a Chrome error that means the browser itself stopped a request before sending it. Also, an ad blocker, privacy extension, or security tool usually causes it. So the problem sits on the visitor side, not on your server.

Stay calm and work through this order:

1. Open the page in an incognito window and see if the error disappears.
2. If it does, turn extensions off one at a time.
3. Add the site to the allow list of the extension that caused it.
4. If the error stays, check company policy and security software.
5. If you own the site, open developer tools and see which request was blocked.

We explain each step below. We also cover how site owners can prevent this problem in the first place.

What does this error message actually say?

The Chromium source code describes this error in one short line: the client chose to block the request. In practice, the client here is the browser, not the server. So the request never leaves the browser.

That is why you will not see these requests in your server logs. The request never arrives. For example, if a script file is blocked, your server records neither a success nor a failure for that file.

The exact wording can change by browser and version, so you may see a similar warning on your screen. Also, you can verify the code yourself in the Chromium network error list.

Also note the difference from server errors. With a timeout, the request reached the server path. Here, it did not. So searching the server for the cause wastes time.

Does ERR BLOCKED BY CLIENT in the console mean your site is broken?

Usually it does not. In practice, a red line in the developer console feels alarming, but it only says the browser stopped a request by its own decision.

If you run an ad blocker yourself, you will see these lines on your own site too. Most of your visitors may not have the same block. In other words, the console line is an observation, not always a fault.

Still, do not dismiss it. If the blocked request is needed for the page to work, you have a real problem. So look at what was blocked:

• If only a tracking or ad request was blocked, the page usually works fine.
• If a form, cart, or payment request was blocked, the user cannot finish the task.
• If a font or stylesheet was blocked, the layout may look wrong.

In short, the question is not the error itself but which request it hit.

What causes the ERR BLOCKED BY CLIENT error most often?

Every cause sits on the browser side, and every cause is a rule match. Also, the browser or a component inside it reads the request address, compares it with a list, and stops the request on a match.

• Ad blocker extensions cut requests to advertising and tracking domains.
• Privacy extensions block analytics and tracking scripts.
• Built-in browser privacy features can stop some requests.
• Company security software and parental control tools close certain addresses.
• Custom filter rules that a user added can match a pattern that is too broad.

For example, an extension may treat every file with "banner" in its address as an ad. Then a harmless image gets blocked too.

This variety matters because the fix depends on the cause. In practice, a visitor can change an extension setting, but only an administrator can change a company policy.

How do you fix ERR BLOCKED BY CLIENT as a visitor?

As a visitor, your goal is to find which component stopped the request and to make an exception for that one site only. You do not need to switch off all your protection.

1. First, reload the page and check whether the error is permanent.
2. Open the page in an incognito window for an extension-free comparison.
3. Open the extensions page and turn suspect extensions off one at a time.
4. After each change, reload the page and check the result.
5. When you find the cause, do not delete the extension. Add this site to its allow list instead.

This order gets you to a result with the fewest changes. Also, because you change one thing at a time, you see exactly what worked.

Opening the same page in another browser is a quick test as well. If it works there, the cause is most likely in your first browser extensions.

On phones, content blocking apps and browser settings can do the same job. The logic stays the same: compare with a blocker-free setup first, then narrow it down.

Why does the incognito window test work?

An incognito window runs the browser in a cleaner environment. Extensions usually start switched off there, and they only run if you allowed them. So you see the extension-free behavior quickly.

If the page opens fine in incognito, an extension or stored site data is the likely cause. Also, this is a strong hint, not proof. The same result can also mean the first window held a bad cookie or cache.

You can read how this mode works in the Chrome Help page on Incognito mode.

If you still see the error in incognito, you may have allowed the extension there, or the block comes from somewhere else. In that case, move on to the company policy and security software section.

How do you find the culprit by turning extensions off one by one?

Switching everything off at once is fast, but it does not tell you which extension is responsible. Going one by one takes a little longer, yet it gives a lasting fix.

Start with ad, privacy, and security extensions, because these are built to block. Then check shopping, coupon, and VPN extensions, since some of them filter content too.

• Turn one extension off, reload the page, and note the result.
• If the error is gone, keep that extension on and open its settings.
• When the error stays, turn the extension back on and move to the next one.
• If none of them helps, check browser security settings and the security software on the computer.

Also, an extension may hold several filter lists. In that case, disabling the single list costs you less protection than turning off the whole extension.

A recently installed "security" or "discount" extension is a common suspect. In practice, these extensions ask permission to read and filter page content, and sometimes they go too far.

How do you add a site to the blocker allow list?

Menu names change between extensions and versions, so we do not give exact button text. The general logic is always the same: click the extension icon and look for an option to pause protection or add an exception for this site.

When you use that option, the extension turns off only on that site. Protection continues everywhere else. So you solve the problem without giving up your security.

One more point matters here. Only add exceptions for sites you trust. Turning off a blocker on a site you do not know defeats the purpose of the protection.

After you add the exception, fully reload the page. If needed, clear the browser cache, because an old block decision can stay stored.

For example, a reader may say the comment box on a news site never opens. If a third party script loads the box and the blocker cuts it, nothing is wrong with the site. Once the reader adds an exception, the box appears.

What if company policy or security software blocks the request?

On a work or school device, the block may not come from an extension at all. Also, it can come from a policy that an administrator set. Chromium uses a separate code for that case: the URL block list configured by the domain administrator.

Do not try to bypass an administrator policy. In practice, it breaks your organization rules, and it counts as circumventing a system. Instead, explain why you need access for work and ask the administrator for an exception.

If security software is the cause, check the web protection settings of that software. If it keeps blocking a site you consider safe, tell the site owner so they can look into the reason.

On managed networks, administrators sometimes close sites by category. If your site landed in the wrong category, a visitor can report it to their IT team.

How do you diagnose ERR BLOCKED BY CLIENT as a site owner?

As the site owner, first find out which request was blocked. Open the browser developer tools, go to the network tab, and reload the page. Blocked requests usually show in red and carry this error in the status column.

You can read more in the Chrome DevTools network documentation.

1. Open developer tools and choose the network tab.
2. Reload the page and filter the red rows.
3. Check whether the blocked address belongs to your domain or to a third party.
4. Open the same page in a profile with no extensions and compare.
5. Decide whether the blocked file is needed for the page to work.

This diagnosis tells you two things. Is the problem really in your file, or is it in the visitor environment? In many cases the answer is the second one.

Write down the blocked address, the date, the browser, and the result of the clean comparison. This note saves time when you later talk to your team or a developer.

Why do file and folder names get caught by blocker lists?

Blocker lists work with general patterns. Also, a file whose address contains certain words can match even if it is not an ad. In other words, the list looks at the shape of the address, not at what the file really is.

This shows up most when you name your own images, scripts, or folders. For example, naming a campaign image "banner" can stop that image from loading for some visitors.

Which patterns cause trouble differs from list to list, so we do not give a fixed list of banned words. In practice, the general principle is simple: do not let your file names borrow words from the advertising, tracking, or analytics world.

You cannot always do this. You do not choose the file names of a third party service. But you do choose the names of your own assets, and being careful there costs almost nothing.

A word alone may not trigger a block. Also, a blocker looks at the whole address, the domain, and the request type together. Still, a neutral name lowers all of these risks from the start.

Which naming patterns should you watch out for?

The table below turns the general principle into examples. In practice, it is not a banned word list, but a way to think about risk. Real behavior depends on the list your visitor uses.

The first two rows are about naming. The last two rows are about architecture. Also, you can fix a name easily, but you need to think about architecture from the start.

How do blocker lists work, and why can we not know everything?

Communities or companies write blocker lists and update them regularly. In practice, a new pattern can join a list, and an old one can leave. So a file name that causes no problem today may cause one in a few months.

Besides, every visitor uses a different list. One person blocks what another person sees. That is why a sentence like "this word is always blocked" is misleading.

The practical result is this: instead of looking for a fixed rule, build habits that lower the risk. Neutral file names, separating critical functions from tracking, and regular testing work no matter how the lists change.

For example, once a month you can open your key pages in a profile with a blocker and walk through the form and cart flow. Also, this short test is far cheaper than a long diagnosis later.

Why should you not tie a critical function to a third party tracking script?

If a button waits for a tracking script to load, that button will not work for every visitor who uses a blocker. Worse, the visitor notices but cannot tell you.

In a healthy design, the main flow does not depend on tracking. In practice, the button, the form, and the payment run on your own code. Tracking is a layer on top that does not break the flow even if it fails.

• A form submit should not wait for a tracking event to finish.
• The payment step should move forward even when an ad script does not load.
• The page should stay readable even if a third party font or widget is blocked.

Also, your code must keep going without errors when the script is missing. The easiest test is to try the site yourself with a blocker on.

This approach protects you from network outages and slow connections too. When a third party service goes down, your site stays up. Also, that is a free benefit of the precaution.

How does ERR BLOCKED BY CLIENT lead to measurement loss?

Analytics and ad measurement usually rely on a script in the browser and the requests it sends. If those requests are blocked, the visit or conversion is not recorded. Your reports then show less than what really happened.

The size of the gap depends on your site and your audience, so we give no percentage. Audiences that are more technical may use blockers more often.

If your conversion counts look strangely low, this can be one reason. For the full list of other reasons, read our post on missing GA4 conversions. We do not repeat that content here.

You can learn how tags work in our Google Tag Manager guide. To keep campaign links tidy, our UTM builder helps as well.

When conversion data going to ad platforms is incomplete, the platform optimizes with incomplete data. So measurement loss is not only a reporting issue. It can also affect ad performance indirectly. For the Meta side, see our Meta Pixel guide.

How do forms and payment flows break because of this error?

The break usually looks like this. In practice, a piece of code on the page depends on a third party script before it submits a form or starts a payment. The script gets blocked, the code throws an error, and the flow stops. Also, the user clicks the button and nothing happens.

This is the most expensive scenario, because the user quietly leaves. You also see no error on the server, since the request never arrived.

Take these precautions:

• Separate the submit code from the tracking call.
• Wrap the tracking call in a structure that catches errors.
• Show the user clear feedback if something fails.
• Test the critical flow regularly in a browser with a blocker.

Example scenario: on a contact form, a click on send first fires an ad conversion event, and only then does the form go out. When the blocker cuts the event, the form never goes out either.

How can you serve visitors with blockers without errors?

The goal is not to beat the blocker. In practice, the goal is a site that works even when a blocker is on. Trying to evade a blocker disrespects the visitor choice, and it rarely lasts.

Instead, build your site to degrade gracefully. If tracking is missing, the site still works and only the measurement is incomplete.

• Serve the core content and functions from your own domain.
• Make third party components optional.
• Do not let a missing component leave the page empty or broken.
• For measurement, consider complementary methods that respect privacy and consent rules.

For a complementary approach, read our post on server side measurement. Respecting privacy and consent rules always comes first.

Can you fix this error from the server side?

No, because the browser makes the block before the request reaches your server. Changing server settings, cache, or firewall rules will not remove this error. Also, the only server side step is to make your resource addresses more neutral.

A common mistake is to report the problem to the hosting provider. The provider can see nothing in the logs, because there was no request. So check the client side first.

Another common mistake is to warn visitors not to use a blocker. Some visitors dislike that message and leave. In practice, a better path is to make the site work with the blocker on.

If the connection from your CDN to your server is the real problem, that is a different case. For that, see our post on Cloudflare error 522.

When is the problem really on your site?

Not every ERR BLOCKED BY CLIENT line is harmless. The signs below suggest the cause may be on your side.

• A script or stylesheet on your own domain is the blocked request.
• The error also shows in a clean profile with no extensions.
• Many different visitors report broken features on the same page.
• The blocked file name looks like an ad or tracking pattern.

If one of these signs fits, renaming the file or moving it to a different path is often enough. Remember to update every place that points to the old address.

Blocked images and icons belong here too. If a logo is missing on your own page, check the status of that request in developer tools first. If an icon is missing in search results, that is a separate topic. We cover it in our post on the favicon not showing in Google.

For example, a gallery library may add an image whose file name contains an ad word. Also, a few visitors cannot see the images. After you simplify the name, the complaints stop.

Which tools and methods help you test this?

You do not need an expensive tool. In practice, the browser developer tools and a clean profile are usually enough. Open two profiles: one with no extensions and one with a popular blocker installed.

• In the clean profile, open the page and record the errors in the network tab.
• In the blocker profile, repeat the same step and compare the difference.
• Complete critical flows such as forms, cart, and payment in both profiles.
• Repeat the same test in a second browser.

If the two profiles show no functional difference, you can relax. If they do, that difference shows exactly what you need to fix.

To test campaign links, our guide to UTM parameters can help. Also, this error may point to heavy dependence on third party parts. Fewer dependencies improve both speed and resilience; see how JavaScript affects site speed.

How does our team handle this error?

At Talha Aslan and team, we start by clarifying the question: did you see this in the console, or did a page really fail to open? These are two very different situations.

Then our checklist runs like this:

1. We identify the blocked request and its domain.
2. We compare with a profile that has no extensions.
3. We check whether the function depends on tracking.
4. If needed, we fix naming and load order.
5. When measurement is lost, we read the reports with that in mind.

If you want to build resilience like this into your site from the start, look at our web design service. For campaign measurement, our Google Ads management page can guide you.

What should you remember about ERR BLOCKED BY CLIENT?

In short, this error says a component on the browser side stopped a request by its own decision. For a visitor, the fix is to find the extension and allow the site. For a site owner, the fix is to build critical functions independent of tracking.

A console line is not always a fault. What matters is which request was blocked. Measurement loss is a separate result, so keep it in mind when you read your reports.

To read your conversion rates correctly, you can use our conversion rate calculator. Also, this content is for technical information. For company network policies, ask your system administrator.