Is ERR_RESPONSE_HEADERS_TOO_BIG the same as a 431 error?

No, and the direction is the giveaway. HTTP 431 Request Header Fields Too Large is a status code the *server* sends back because it decided *your request* headers were too big — it's a real HTTP response with a status line. ERR_RESPONSE_HEADERS_TOO_BIG is different: it's Chrome's own network stack refusing to accept the *server's response* because the combined response headers overflowed Chrome's internal buffer. There is no HTTP status code involved — the response never finishes parsing, so you get Chrome's error page instead of a page from the site. 431 is the server complaining about you; ERR_RESPONSE_HEADERS_TOO_BIG is your browser complaining about the server. They also live at opposite ends of the round trip: 431 is about the request headers going out, this error is about the response headers coming back.

Why does clearing cookies for one site fix it instantly?

Because in the overwhelming majority of cases the bloat *is* the cookies. Every cookie a site sets gets echoed back in the response headers on subsequent responses (and re-set via Set-Cookie), and browsers accumulate them. One app that keeps appending state to a cookie, sets hundreds of small cookies, or stuffs a large SAML assertion or JWT into one, and the pile eventually crosses Chrome's 256 KB ceiling for that origin. Clearing cookies for just that site drops the pile back to zero, so the next response fits and the page loads — which is exactly why it looks like a magic fix. It also tells you something: if wiping cookies cures it, the problem is state the site accumulated in your browser, not a static misconfiguration that would hit a fresh visitor. Note that this is a symptom fix; if the app rebuilds the oversized cookie, the error comes back.

A first-time visitor with no cookies still gets it. Now what?

Then the cookies theory is out and the response itself is genuinely too big before any browser state enters the picture. Fetch the URL from outside your browser — the response headers you get back are the raw truth, with none of your accumulated cookies in the mix. If an external HTTP check also shows enormous headers, the origin (or a proxy in front of it) is emitting them: a giant Content-Security-Policy, a runaway Set-Cookie loop that fires on the very first response, hundreds of Link preload headers, or an appliance injecting large headers on the way out. Read which header is doing it and shrink that one thing. If the external check shows perfectly normal headers while only your browser fails, you're back to accumulated local state — cookies or an extension rewriting responses.

Views: 29

ERR_RESPONSE_HEADERS_TOO_BIG: Headers Over 256KB

ERR_RESPONSE_HEADERS_TOO_BIG means Chrome hit its 256 KB response-header cap — usually runaway cookies. Find it in 3 checks. 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 shows a bare error page — “This page isn’t working” — with the code ERR_RESPONSE_HEADERS_TOO_BIG at the bottom. No content, no HTTP status, nothing from the site itself. The server almost certainly answered; Chrome just refused to accept the answer.

The reason is a hard limit most people never hear about until they hit it. Chrome’s network stack buffers the response headers as they arrive, and that buffer has a ceiling. In the Chromium source it’s the kMaxHeaderBufSize constant — kHeaderBufInitialSize (4 KB) multiplied by 64, which works out to 256 KB. If Chrome reads that many bytes of headers without finding the start of the response body, it gives up and fails the transaction with ERR_RESPONSE_HEADERS_TOO_BIG. This is about the headers only. Your 40 MB image is fine. It’s the metadata in front of the body that blew the budget.

Symptoms

The exact code is ERR_RESPONSE_HEADERS_TOO_BIG, shown on Chrome’s generic error page with no HTTP status number.
It usually hits a specific site — the one whose cookies or responses got fat — while everything else loads normally.
It often appears after you’ve been logged in and clicking around a while, not on the first visit. The state built up.
Clearing cookies for that one site makes it vanish immediately (and it may creep back later).
Firefox and Safari may load the same page fine — their header limits are larger or handled differently, so this is frequently a Chrome-only symptom.
Curl or an external fetch of the URL succeeds and shows you an unusually long block of response headers.

What ERR_RESPONSE_HEADERS_TOO_BIG Actually Means

It means the sum of all response headers crossed 256 KB. Not one header — the total. Chrome doesn’t care whether that’s one absurdly long Content-Security-Policy or four hundred separate Set-Cookie lines; it’s counting bytes in the header block, and when the count passes the buffer size before the blank line that ends the headers, it aborts.

That framing matters because it changes where you look. People see “headers too big” and start auditing individual headers for one obvious monster. Sometimes there is one. More often it’s death by a thousand cuts: an accumulation of cookies, each small, that together add up. The single most common real-world cause is a site that keeps writing to cookies — session data, feature flags, tracking IDs, a growing list of “recently viewed” items shoved into a cookie instead of a database — until the pile it sends and re-sets on every response tips over the edge.

It’s worth being precise about what this error is not. It is not HTTP 413 (a request body too large), not 414 (a request URI too long), not 431 (the server rejecting your request headers). All three of those are the server making a decision and returning a status. ERR_RESPONSE_HEADERS_TOO_BIG is Chrome making the decision, locally, about a response — no status code exists because Chrome never got far enough to produce one.

Top Causes

Cookie accumulation — The classic. An application stores growing state in cookies, or sets many cookies across many paths, and the browser’s pile for that origin eventually exceeds 256 KB when combined with everything else in the response. This is the version that “clear cookies” fixes and that comes back if the app rebuilds the cookie.
One oversized header — A monster Content-Security-Policy with hundreds of source entries, a bloated Set-Cookie carrying a large encoded session or SAML token, or a Report-To/NEL block that grew out of control. Any single header can eat the budget alone.
A Set-Cookie loop or misconfigured session — A bug where the server re-issues a large batch of cookies on every response, or splits a big value into dozens of chunks. This can hit even a first-time visitor because the very first response is already huge.
A proxy or middlebox adding headers — A reverse proxy, WAF, or SSO gateway that injects large headers (auth context, debug info, a stack of Via/X-Forwarded-* lines, preload Link headers) on top of what the origin already sent. The origin looks innocent; the header bloat is added in transit.

Diagnose with DechoNet

HTTP Check fetches the URL from outside your browser and shows you the response headers the server actually sends — with none of the cookies your browser has piled up. That external view is the whole diagnosis. If the HTTP check comes back with a normal, small set of headers, the 256 KB overflow is happening only in your browser, which means accumulated cookies (or an extension) — clear that site’s cookies and you’re done. If the HTTP check itself shows a huge header block, the origin or a proxy in front of it is the source, and you can read exactly which header is oversized and take it back to whoever owns that server.

Resolution Checklist

Confirm the scope. One site or everything? One site points at that site’s cookies or responses; genuinely everything would point at something local like an extension mangling responses.
Clear cookies for the affected site (Chrome Settings → Privacy → Cookies → See all site data → search the domain → delete). If the page loads, you’ve confirmed cookie accumulation.
Run an external HTTP check on the URL. Normal headers there but failure in your browser = local cookie/state problem, and you’re finished. Huge headers there = server-side, keep going.
If it’s server-side, read the header block and find the offender: a giant CSP, a fat session cookie, a Set-Cookie loop, or a proxy-injected pile. Shrink or fix that one thing.
If the culprit is cookie-stored state, move it where it belongs — a server-side session with a short cookie ID, not the whole payload in the cookie. This is the only fix that stays fixed.
If a proxy or gateway is adding the headers, trim its injected headers or raise the header buffer on that hop as a stopgap while you shrink the real cause.

When to Escalate

If an external HTTP check shows oversized headers, this is a server or infrastructure fix, not something the visitor can solve. Hand it to whoever runs the origin or the proxy with the specific header named — “the CSP is 300 KB” or “we’re setting 600 cookies” is an actionable bug report.
If the app stores meaningful state in cookies by design, escalate it as an architecture issue, not a header tweak. Raising a buffer somewhere buys time; the payload belongs server-side, and until it moves there the error will keep resurfacing for whoever accumulates enough state.