How is ERR_INVALID_CHUNKED_ENCODING different from ERR_INCOMPLETE_CHUNKED_ENCODING?

They're two different failures in the same framing, and the difference tells you what to go fix. A chunked response is a series of chunks, each introduced by a line giving its size in hexadecimal, terminated by a zero-length chunk. ERR_INCOMPLETE_CHUNKED_ENCODING (Chromium net error -379) means the chunks themselves were well-formed but the stream ended before that final zero-length chunk arrived — a truncation, usually because a backend crashed or timed out mid-response. ERR_INVALID_CHUNKED_ENCODING (net error -270) means the chunk *structure* is wrong: a size line that isn't valid hex, a missing or misplaced CRLF, or bytes where a chunk header should be. Chrome couldn't even parse the framing. The practical tell is consistency. Incomplete is intermittent and size-dependent — it fails on the big or slow responses that cross a limit. Invalid tends to fail the *same way every time* on a given endpoint, because the framing is deterministically broken, not dependent on timing.

Why does it fail in Chrome but curl or another browser loads the page fine?

Because Chrome parses chunked framing strictly and refuses to guess. When it hits a chunk-size line that doesn't conform to the grammar in RFC 9112 §7.1, it aborts rather than try to recover, and the Chromium team has been explicit that they won't add workarounds for servers that emit invalid framing — doing so would break correctly behaving servers. Older or more lenient HTTP stacks sometimes paper over a malformed chunk and render anyway, which is exactly why the same response 'works' in one client and fails in Chrome. That divergence is a symptom of a real bug in what the server (or something in the path) is sending, not a Chrome defect. Reproduce it with `curl --raw -v` so you can see the literal chunk-size lines on the wire — that's where the malformed bytes become visible.

Is ERR_INVALID_CHUNKED_ENCODING a server problem or a client problem?

Almost always the server or a middlebox in front of it, and you can prove which in one step. The framing is generated upstream; the browser only reads it. Fetch the same URL from outside your browser — a server-side HTTP check, or `curl --raw` from another machine — and look at the raw response. If the chunk framing is malformed from there too, the fault is at the origin or an upstream proxy, and you debug the response, not your laptop. If the external fetch comes back clean and only your browser fails, suspect something rewriting the body on your side: a local proxy, antivirus web shielding, or a corporate TLS-inspection appliance that mutates the entity body without recomputing the chunk sizes.

Views: 10

ERR_INVALID_CHUNKED_ENCODING: Fix Broken Framing

ERR_INVALID_CHUNKED_ENCODING: the server's chunk framing is malformed, not truncated. Find double-chunking or stray output. 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’s console shows net::ERR_INVALID_CHUNKED_ENCODING, often alongside a 200 (OK) status, and the page renders blank or half-broken. The server did respond — the status line and headers arrived — but the body was framed as a chunked stream that Chrome couldn’t parse. This is not a truncated response that got cut short. The bytes describing the chunks are themselves wrong.

Symptoms

The console shows net::ERR_INVALID_CHUNKED_ENCODING, frequently paired with a 200 (OK) that makes it look like the request succeeded.
The page is blank or missing content; JavaScript and CSS may load truncated, breaking form submissions and dynamic behavior.
The response headers include Transfer-Encoding: chunked.
It fails consistently on the same endpoint — not the intermittent, size-dependent flakiness of a truncated stream.
The same URL may render fine in curl or a more lenient browser, which makes it look like a Chrome bug.

What This Error Actually Means

When a server sends a body without knowing its length up front, HTTP/1.1 uses chunked transfer coding (RFC 9112 §7.1). The body is a sequence of chunks, and each chunk has a strict shape: a line giving the chunk’s size in hexadecimal, a CRLF, the chunk data, another CRLF, then the next chunk — until a final zero-length chunk (0\r\n\r\n) marks the end. The size lines are the scaffolding that tells the client where each chunk begins and ends.

ERR_INVALID_CHUNKED_ENCODING (Chromium net error -270) is Chrome saying that scaffolding is broken. Somewhere in the stream it expected a hexadecimal size line and got something that doesn’t parse — a non-hex character, a missing CRLF, a size that doesn’t line up with the bytes that follow, or garbage injected between chunks. Chrome parses this grammar strictly and does not try to recover; it aborts.

The distinction that matters: this is not ERR_INCOMPLETE_CHUNKED_ENCODING, where the chunks are valid and the stream just ends early. Here the chunks are malformed. The response didn’t run out — it was mis-assembled. That points you at whatever wrote the framing: the application, a framework’s HTTP layer, or a proxy that re-touched the body without fixing the sizes.

Top 3 Causes

Double or conflicting framing. The response carries both a Content-Length and Transfer-Encoding: chunked, or something in the path chunks a body that was already chunked. Per RFC 9112 §6.1 chunked wins and the length must be dropped, but a hand-rolled HTTP layer that writes its own chunk markers and lets the server chunk again produces byte sequences that no longer parse as valid chunks. This is the classic cause behind frameworks and runtimes that emit their own chunk sizes incorrectly.
Stray bytes corrupting the size lines. A chunk starts with a hex size and a CRLF, and nothing is allowed to appear outside that structure. If the application prints anything into the stream that the framer doesn’t account for — a PHP notice or warning echoed mid-response, whitespace or a newline after a closing ?>, a UTF-8 BOM prepended by an editor, stray debug output — the byte offsets shift and the next “size line” Chrome reads is no longer valid hex. The framing is arithmetically off from the first injected byte onward.
A middlebox rewriting the body without re-framing. A compression proxy, a WAF, or a TLS-inspection appliance that mutates the entity body — injecting a script, stripping content, altering encoding — but doesn’t recompute the chunk sizes leaves the declared sizes inconsistent with the actual bytes. The origin framed the response correctly; the device in the middle broke it.

Diagnose with DechoNet

HTTP Check fetches the URL from our servers, outside your browser and your local network, and shows you the response headers and status. If it confirms Transfer-Encoding: chunked and the response is malformed from there too, the fault is at the origin or an upstream proxy — not your browser, extensions, or local security software.
If the external fetch comes back clean but your browser still fails, the framing is being broken on your side of the connection: a local proxy, antivirus web shielding, or a corporate TLS-inspection appliance mutating the body. That narrows the search to your machine and network path immediately.
Because this failure is deterministic, one external fetch is enough to settle server-vs-client — you don’t need to hammer it the way you would an intermittent truncation.

Resolution Checklist

Confirm it’s chunked, not fixed-length. Check the response headers for Transfer-Encoding: chunked. If you see Content-Length with no chunked encoding, you’re looking at ERR_CONTENT_LENGTH_MISMATCH instead — a different framing bug.
Look at the raw wire, not the rendered page. Run curl --raw -v against the URL and read the literal chunk-size lines. Malformed hex, a stray blank line, or a BOM at the top of the body will be visible here in a way it never is in DevTools.
Kill double-framing. Make sure your app or framework isn’t writing its own chunk markers while the server also applies Transfer-Encoding: chunked, and that no response carries both Content-Length and chunked. Pick one framing and let a single layer own it.
Hunt stray output. Check for PHP notices/warnings printed into the body, whitespace or newlines after ?>, an editor-added UTF-8 BOM, or debug echo/print statements leaking into the response stream. Any byte outside the chunk structure corrupts it.
Suspect the middle if the origin looks fine. If the application emits valid framing in isolation but the browser sees garbage, a proxy, WAF, compression layer, or TLS-inspection device is rewriting the body without fixing the sizes. Test with it bypassed.
Isolate client vs. server. Fetch the URL with an external HTTP Check or curl --raw from another network. Reproduces externally → fix the origin or upstream proxy. Only fails in your browser → look at local proxies, corporate MITM, or antivirus.

When to Escalate

If the raw response looks correctly framed from the origin but a CDN or edge in front of it serves malformed chunks, escalate to whoever owns that edge — the body is being rewritten at a layer you don’t control, and only their config will show the transform that skipped re-framing.
If the malformed framing traces to a framework or runtime’s HTTP stack rather than your own code, treat it as a library bug: pin or upgrade the version, and disable any manual chunking you added on top of it, rather than trying to sanitize the output downstream.