Fix ERR_BLOCKED_BED_BY_RESPONSE When a Site Refuses to Load

You're trying to open a page—maybe a banking portal, a video stream, or a PDF viewer—and Chrome just shows a blank white screen. Sometimes you get a message like "This page isn't working" with the code ERR_BLOCKED_BY_RESPONSE at the bottom. The URL is correct, the server is up, but Chrome refuses to render the content.

This usually happens when the server sends a response that Chrome interprets as a block. The most common trigger is a missing or incorrect X-Frame-Options header, or a strict Content-Security-Policy that forbids the resource from loading. It's not a virus, not a network issue—it's a security feature fighting with the browser.

Here's the plain-English version: when a server responds, it can include extra instructions about who is allowed to display or run the content. If those instructions say "don't let anyone embed this in a frame," and the site is trying to load in an iframe, Chrome slams the door shut. Same thing happens if a script or image is blocked by a policy. The error code is just Chrome saying, "The server told me not to show this, so I won't."

Below are the steps I use to fix this on Windows, Mac, and Linux. Start with the easy ones—they solve most cases. Move to the server-side fixes only if you control the website itself.

Step 1: Reload the page with a hard refresh

Sometimes the response header is cached. A hard refresh forces Chrome to ignore the cache and re-request the page.

1. Press Ctrl+Shift+R on Windows or Linux, or Cmd+Shift+R on Mac.
2. Watch the tab's loading spinner. If the page loads, you're done.
3. If not, close the tab and try again in a new tab.

After a hard refresh, you should see either the page content or the same error. If the error persists, move on.

Step 2: Clear site data for that specific site

Clearing just the site's cookies and cache often gets rid of a stale header or a bad saved state.

1. Click the lock icon (or the "Not secure" warning) in the address bar.
2. Click "Site settings."
3. In the permissions page, click "Clear data" at the bottom.
4. Confirm by clicking "Clear" in the popup.

After clearing, reload the page. If it loads, great. If not, you haven't lost anything—site settings like passwords and bookmarks are untouched.

Step 3: Disable browser extensions

Extensions that block ads, scripts, or privacy trackers often interfere with response headers. They can strip or add headers, causing this exact error. I've seen it with uBlock Origin and Privacy Badger.

1. Click the three-dot menu (top-right), then go to "Extensions" → "Manage extensions."
2. Toggle off every extension. Yes, all of them.
3. Reload the offending page.

If the page loads, turn your extensions back on one by one. Reload the page after each one to find the culprit. Leave that one disabled or look for an update.

Step 4: Check Chrome flags (only if you're comfortable)

Some experimental flags like "SameSite by default cookies" or "Partitioned cookies" can cause this error. They're not stable in all versions.

1. Type chrome://flags in the address bar and press Enter.
2. Search for "SameSite" and "cookies."
3. Set any related flags to "Disabled" or "Default."
4. Click "Relaunch" at the bottom.

After relaunching, try the site again. If it works, you know a flag was the issue. You can leave those flags disabled permanently.

Step 5: Update Chrome and your OS

Older Chrome versions sometimes mishandle certain header combinations. I fixed this on a Windows 10 machine by updating from Chrome 88 to 91—the error vanished.

1. Go to chrome://settings/help.
2. Wait for Chrome to check for updates. If an update is available, click "Relaunch."

After the update, test the site. Also make sure your operating system is up to date. A missing security patch can alter how Chrome responds to headers.

Step 6: Try a different browser or incognito mode

Incognito mode disables extensions and uses a clean session. That tells you if the problem is browser-specific.

1. Open an incognito window (Ctrl+Shift+N on Windows, Cmd+Shift+N on Mac).
2. Go to the URL that failed.

If it loads in incognito, the problem is your profile or an extension. If it fails even in incognito, the problem is the server's response itself.

Step 7: Check the server response headers (if you own the site)

When all browser-side fixes fail, the blame falls on the server. I've seen this on misconfigured Apache and Nginx servers. The fix is to adjust the headers that the server sends.

Open Chrome's DevTools (F12), go to the Network tab, reload the page, and click the failed request. Look at the Headers tab for these two:

• X-Frame-Options — if it says DENY or SAMEORIGIN, and the page is embedded in an iframe, that's your culprit.
• Content-Security-Policy — look for directives like frame-ancestors, script-src, or default-src that might block the resource.

If X-Frame-Options is set to DENY, you can either change it to SAMEORIGIN (if you trust same-origin embeds) or use Content-Security-Policy: frame-ancestors instead. The latter is more flexible.

For Nginx, add or edit in the server block:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;

For Apache, in the .htaccess or virtual host:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self'"

After changing, restart the web server (e.g., sudo systemctl restart nginx on Linux). Reload the page and see if the error clears.

Step 8: Test with a URL shortener or a direct IP

If you're not the server admin and the error only happens on one site, try accessing the same content via a different URL. For example, if you're trying to watch a video on a site, copy the direct .mp4 link and open it in a new tab. If that works, the issue is specifically with the page embedding the video.

What if it still fails?

If you've done all the above and the error persists, it's time to contact the website owner. Send them the exact error code and what you've tried. They'll need to check their server logs—look for entries with status 200 but with Content-Security-Policy violations. In my experience, 90% of these cases are fixed by clearing site data or disabling an extension. The rest are server misconfigurations that the admin has to fix.

One last thing: don't ignore the possibility of a content delivery network (CDN) caching a bad header. If you're the admin, purge your CDN cache after changing headers. I've seen Cloudflare serve an old X-Frame-Options for an hour after the origin was corrected.

That's the whole process. Go through the steps in order—most people find the fix within the first three. Good luck.