Why does the page load fine sometimes and fail other times?

Because the failure is timing-dependent, and that's the biggest tell that you're dealing with a truncated stream rather than a config error. A chunked response is a promise the server makes at the top — 'I don't know the total length yet, so I'll send it in pieces and tell you when I'm done.' If the process generating that response dies partway through (a PHP worker that hits its memory limit on a big query, a backend that times out, an nginx worker that can't write its buffer to disk), the connection closes without the terminating zero-length chunk. Chrome was told to keep reading until that final chunk arrives; when the socket closes first, it raises ERR_INCOMPLETE_CHUNKED_ENCODING. A small or cached response finishes before the fault triggers, so it loads; a large or slow one crosses the failure threshold, so it doesn't. Intermittent-by-size is the signature.

How is this different from ERR_CONTENT_LENGTH_MISMATCH?

They're two ways of counting the same thing, and the difference tells you where to look. Both mean the body arrived short, but they use different framing. ERR_CONTENT_LENGTH_MISMATCH happens when the server sent an explicit `Content-Length: N` header and then delivered fewer than N bytes — a fixed promise it couldn't keep. ERR_INCOMPLETE_CHUNKED_ENCODING happens when the server used `Transfer-Encoding: chunked` instead of a length, and the stream ended without the last-chunk marker. The chunked path is what backends use when they generate output on the fly and don't know the size upfront — dynamic pages, streamed API responses, anything piped through a template engine. So a content-length mismatch points you at a static or fully-buffered response, while an incomplete chunked encoding points you at something generating the body live and dying mid-generation.

Is ERR_INCOMPLETE_CHUNKED_ENCODING a browser bug or a server problem?

Almost always the server, and you can prove it in one step. The browser is doing exactly what the spec tells it to: `Transfer-Encoding: chunked` means 'read chunks until a zero-length one,' and Chrome refuses to render a body it knows is incomplete rather than hand you half a page. The truncation happened before the bytes reached the browser. Fetch the same URL from outside the browser — a server-side HTTP check, or `curl -v` from another machine — and watch whether the response completes with its `0\r\n\r\n` terminator. If the external fetch also comes up short, the fault is at the origin or an upstream proxy, not your browser or your extensions. If only your browser fails, suspect a local proxy, a corporate TLS-inspection appliance, or antivirus web shielding sitting between you and the network.

Views: 21

ERR_INCOMPLETE_CHUNKED_ENCODING: Response Cut Short

ERR_INCOMPLETE_CHUNKED_ENCODING means a chunked response ended before its final chunk. Backend crash, nginx temp, or proxy? 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

A page starts rendering and then stops — half the content, a broken image, an API call that returns most of its JSON and then nothing. Chrome’s console shows net::ERR_INCOMPLETE_CHUNKED_ENCODING. The server sent a response, the browser started reading it, and then the bytes ran out before the response said it was finished.

Symptoms

The page loads partially — the top renders, the bottom is missing or cut off mid-element.
DevTools Network tab shows the request as (failed) or (canceled) with ERR_INCOMPLETE_CHUNKED_ENCODING in the console.
It’s intermittent: the same URL works on one load and fails on the next, or fails only for larger pages.
The response headers include Transfer-Encoding: chunked (not Content-Length).
Static assets are fine; the failures cluster on dynamic pages or streamed API endpoints.

What This Error Actually Means

When a server doesn’t know how long a response will be before it starts sending it — a page assembled from a database query, a streamed export, anything generated on the fly — it can’t set a Content-Length header. HTTP/1.1 solves this with chunked transfer coding (RFC 9112 §7.1): the body is sent as a series of chunks, each prefixed with its size in hex, and the whole thing is terminated by a last-chunk — a chunk of size zero (0\r\n) followed by an optional trailer and a final empty line. That zero-length chunk is the “I’m done” signal. Until it arrives, the client keeps reading.

ERR_INCOMPLETE_CHUNKED_ENCODING is Chrome telling you the connection closed before that last-chunk showed up. The server framed the response as chunked, promised more was coming, and then the socket went quiet. Chrome won’t render a body it knows is truncated — it aborts rather than show you a page that’s silently missing its tail.

The important thing to internalize: this is not a corruption error or a checksum failure. The bytes that arrived were fine. The problem is that the framing said “keep going” and the stream said “goodbye,” and those two disagreed. That disagreement almost always means something upstream died or gave up in the middle of producing the response.

Top 3 Causes

The backend crashed or timed out mid-response. A PHP-FPM worker hits memory_limit on a heavy page, a max_execution_time fires, an application throws after it has already flushed headers and part of the body, or the app server is killed by the OOM reaper. Headers (including Transfer-Encoding: chunked) already went out; the terminating chunk never does. This is the classic cause behind the intermittent, size-dependent failures — the fault only triggers on the requests big or slow enough to hit the limit.
The reverse proxy can’t finish buffering the response. nginx buffers upstream responses to temporary files, and if it can’t write them — wrong ownership on its temp/cache path (the well-known chown www-data /var/lib/nginx fix), a full disk, or an exhausted proxy_temp_path — it abandons the response partway. The origin app is healthy; the proxy is the one dropping the tail.
An HTTP/1.0 backend speaking chunked through a proxy. Chunked coding is an HTTP/1.1 feature; it must not be used on HTTP/1.0. If your app emits chunked responses but nginx talks to it over HTTP/1.0 (the default for proxy_pass), nginx can’t reassemble them cleanly and the browser sees a broken stream. The fix is proxy_http_version 1.1; plus clearing the Connection header on the upstream.

Diagnose with DechoNet

HTTP Check fetches the URL from our servers, outside your browser and your local network. If the response completes cleanly from there but fails in your browser, the truncation is happening on your side — a local proxy, a TLS-inspection appliance, or antivirus web shielding — not at the origin.
The same check shows you the response headers. Confirm the server is actually sending Transfer-Encoding: chunked (and not, say, a Content-Length that would point you at a different error), and whether a CDN or reverse proxy is in the path. Knowing whether the framing is chunked at all is the first fork in the decision tree.
Re-run it a few times. Because the failure is intermittent and size-dependent, a single clean fetch doesn’t clear the server — but a fetch that reproduces the truncation from outside your network confirms the fault is upstream, and tells you to stop debugging your laptop.

Resolution Checklist

Confirm it’s chunked, not fixed-length. Check the response headers for Transfer-Encoding: chunked. If you see Content-Length instead, you’re chasing the wrong error — that’s ERR_CONTENT_LENGTH_MISMATCH territory.
Read the backend logs for the failing request. Look for OOM kills, memory_limit/max_execution_time in PHP, worker restarts, or unhandled exceptions that fire after output started. The timestamp lines up with the truncated request.
Raise the limits that are firing. If it’s memory or execution time on large responses, bump memory_limit / max_execution_time (PHP), or the equivalent worker timeout — or better, fix the query or view that’s generating an oversized response.
Check the proxy’s temp/cache directory. For nginx: confirm the worker user owns proxy_temp_path (and /var/lib/nginx), that the disk isn’t full, and that buffering isn’t failing silently. The error log will name the path it couldn’t write.
Fix HTTP/1.0-to-chunked mismatches. If your app sends chunked responses, set proxy_http_version 1.1; and proxy_set_header Connection ""; so nginx speaks 1.1 upstream.
Isolate client vs. server. Fetch the URL with an external HTTP Check or curl -v from another network. Reproduces externally → fix the origin/proxy. Only fails in your browser → look at local proxies, corporate MITM, or antivirus.

When to Escalate

If the backend logs are clean and an external fetch still truncates, escalate to whoever owns the reverse proxy or CDN — the response may be dying at an edge you don’t control, and only their logs will show the aborted upstream read.
If the failures started right after a deploy or a traffic spike, treat it as a capacity problem, not a config bug: something is now large or slow enough to cross a limit that used to have headroom. Roll back or raise the limit while you find the response that grew.