Is ERR_BLOCKED_BY_RESPONSE the same as ERR_BLOCKED_BY_CLIENT?

No, and the difference tells you where to look. ERR_BLOCKED_BY_CLIENT means something on the client side — an ad blocker, a privacy extension, or a Chrome policy — refused to even make the request. ERR_BLOCKED_BY_RESPONSE means the request went out, a response came back (often with a 200 status, which is why it's confusing), and then Chrome blocked it because the response didn't satisfy a cross-origin policy the page had switched on. One is an extension on the visitor's machine; the other is a header mismatch you can fix on the server.

Why does the network tab show status 200 but the resource still fails?

Because the block happens after the response arrives. The server did its job and returned the bytes with a 200. Chrome then checked those bytes against the page's Cross-Origin-Embedder-Policy and found the resource carried no Cross-Origin-Resource-Policy (CORP) header and wasn't fetched with CORS, so it refused to hand the resource to the page. The 200 is real; the enforcement is a second gate after it. That's the signature of the COEP variant, spelled ERR_BLOCKED_BY_RESPONSE.NotSameOriginAfterDefaultedToSameOriginByCoep.

I didn't set up cross-origin isolation on purpose. Where is the COEP header coming from?

Usually a security-header library or a platform default. Helmet, some framework 'secure by default' presets, and a few hosting platforms emit Cross-Origin-Embedder-Policy or Cross-Origin-Opener-Policy without you asking. If you don't actually need cross-origin isolation (SharedArrayBuffer, high-resolution timers), the cleanest fix is to stop sending COEP on the page rather than chasing CORP headers onto every third-party resource you embed.

Views: 14

ERR_BLOCKED_BY_RESPONSE in Chrome: Fix

ERR_BLOCKED_BY_RESPONSE: a COEP/CORP policy blocked a cross-origin resource. Check the page COEP and the resource CORP header. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome fails to load a resource — an image, a script, a font, an iframe — with net::ERR_BLOCKED_BY_RESPONSE, frequently followed by a longer suffix like .NotSameOriginAfterDefaultedToSameOriginByCoep. The confusing part: the network tab often shows the request succeeded with a 200, yet the resource never appears on the page.

Symptoms

The console shows net::ERR_BLOCKED_BY_RESPONSE or a dotted variant (.NotSameOrigin, .NotSameOriginAfterDefaultedToSameOriginByCoep, .CorpNotSameOrigin).
The failing resource is almost always cross-origin — a CDN asset, an ad, an embedded widget, a font from a third-party host.
The response status is 200 OK, so it doesn’t look like a server error.
It started after a dependency bump, a new security-header middleware, or a platform default change — not after touching the resource itself.

What This Error Actually Means

ERR_BLOCKED_BY_RESPONSE is not a network failure. The request went out and the response came back. Chrome then applied one of the cross-origin isolation policies the page had turned on, decided the response wasn’t allowed to be delivered, and dropped it. The block is a policy decision made after a successful fetch, which is why you see a green 200 next to a resource that never loaded.

The policy almost always in play is COEP — Cross-Origin-Embedder-Policy. When a page sends Cross-Origin-Embedder-Policy: require-corp, it’s declaring: every cross-origin thing I embed must explicitly opt in to being embedded. A resource opts in one of two ways — by carrying a Cross-Origin-Resource-Policy (CORP) header that permits the embed, or by being fetched with CORS. If a cross-origin resource does neither, COEP defaults it to same-origin, finds it isn’t same-origin, and blocks it. That exact chain is what the mouthful NotSameOriginAfterDefaultedToSameOriginByCoep is describing.

Two related headers travel with COEP. COOP (Cross-Origin-Opener-Policy: same-origin) isolates the page from windows it opens or that opened it. CORP (Cross-Origin-Resource-Policy) is the header the resource sends to say who may embed it. COEP is the demand; CORP is the consent. The error is what happens when the demand meets a resource that never gave consent.

Top 3 Causes

A COEP page embedding a resource with no CORP header - The headline case. Your page sends Cross-Origin-Embedder-Policy: require-corp (often via a security library you didn’t hand-configure), and you load an image, script, or font from a CDN that doesn’t set Cross-Origin-Resource-Policy. COEP defaults the resource to same-origin, it isn’t, and Chrome blocks it with .NotSameOriginAfterDefaultedToSameOriginByCoep.
A CORP header that’s too strict for the embed - The resource does send CORP, but set to same-origin or same-site when the embed is genuinely cross-origin. The header is present and actively saying “not you,” which surfaces as .CorpNotSameOrigin. Common when a resource meant for first-party use gets reused across domains.
COOP/COEP turned on by a default you didn’t intend - A framework preset or hosting platform emits the isolation headers without you needing SharedArrayBuffer or precise timers at all. Now every third-party embed has to satisfy COEP for no benefit to you, and things that worked yesterday break after a deploy.

Diagnose with DechoNet

HTTP Check shows the exact response headers for any URL. Run it on your page to see whether you’re sending Cross-Origin-Embedder-Policy or Cross-Origin-Opener-Policy — then run it on the failing resource’s URL to see whether it sends Cross-Origin-Resource-Policy. The mismatch between those two answers is the whole bug.
SSL Check confirms the resource’s host is served cleanly over HTTPS, ruling out a mixed-content or certificate problem masquerading as a block.

Resolution Checklist

Read the full error string. The suffix (.NotSameOriginAfterDefaultedToSameOriginByCoep vs .CorpNotSameOrigin) tells you whether the resource is missing CORP entirely or sending a CORP that’s too strict.
Run HTTP Check on your own page. If you see Cross-Origin-Embedder-Policy: require-corp and you don’t actually use SharedArrayBuffer or performance.now() high-resolution timers, the simplest fix is to stop sending COEP — remove it from your security middleware.
If you do need cross-origin isolation, add Cross-Origin-Resource-Policy: cross-origin to the responses of the resources you embed (if they’re yours), or ask the CDN/provider to add it.
For third-party resources you can’t change, switch the page to Cross-Origin-Embedder-Policy: credentialless. It waives the CORP requirement for no-credentials requests, so a CDN asset with no CORP header loads without you touching the CDN.
Re-run HTTP Check on both URLs after the change to confirm the page’s demand and the resource’s consent now line up.

When to Escalate

If the resource is served by a CDN or SaaS you don’t control and it sends no CORP header, escalate to them to add Cross-Origin-Resource-Policy: cross-origin — or move to COEP: credentialless on your side so you don’t have to wait on them.
If the isolation headers appear even after you’ve removed them from your own config, they’re being injected by a proxy, WAF, or hosting layer above your app — hand it to whoever owns that layer, with the HTTP Check output showing where the header enters.
If you genuinely need cross-origin isolation for a feature and a critical third-party embed refuses to send CORP and breaks under credentialless, that’s an architecture decision (proxy the resource first-party) rather than a header tweak.