Browser Handling of Broken and Truncated JPEGs

When network instability interrupts an image download, modern web browsers do not simply fail to display the asset; instead, they employ resilient decoding routines to render as much visual data as possible. This article details the underlying mechanisms browsers and image libraries use to handle missing end-of-file markers, the visual differences between truncated baseline and progressive JPEGs, how decoders conceal errors, and the network-level implications of incomplete data streams.

JPEG Structure and the Missing End-of-Image Marker

A standard JPEG data stream begins with a Start of Image (SOI) marker (0xFFD8) and concludes with an End of Image (EOI) marker (0xFFD9). Between these boundaries lie metadata headers, quantization tables, Huffman tables, and scan data encoded in Minimum Coded Units (MCUs).

When a network connection drops, the stream terminates prematurely without the final EOI marker. Underlying browser graphics engines (such as Skia in Chromium, Core Graphics in WebKit, or MozJPEG/libjpeg-turbo in Gecko) monitor incoming bytes. Upon detecting a connection close without an EOI marker, the decoder treats the stream as truncated, synthesizes an internal EOI marker, and attempts to parse all successfully received MCUs up to the point of disconnection.

Baseline vs. Progressive Stream Truncation

The visual outcome of a truncated image depends heavily on the compression mode used during encoding.

Baseline JPEGs

Baseline JPEGs store scanlines sequentially from top to bottom.

• Partial Display: The browser decodes each MCU row sequentially. If the data stops mid-transfer, the top portion of the image renders with full fidelity.
• Padding: For the remaining unreceived rows, decoders commonly fill the missing pixels with a default neutral color (typically gray or black) or leave the background canvas exposed.

Progressive JPEGs

Progressive JPEGs store image data in multiple full-frame passes, gradually refining frequency coefficients and color detail.

• Full-Frame Rendering: Even with an early connection break, the browser often has enough data to render the entire frame.
• Quality Degradation: Depending on how many passes were completed before failure, the truncated image appears blurry, pixelated, or lacking high-frequency color detail, but the composition remains fully visible rather than sliced off at the bottom.

Error Concealment and Entropy Decoding Failures

Network instability can cause bit corruption rather than a clean cut-off. If byte corruption alters the entropy-coded segments (the Huffman or arithmetic data), decoders face desynchronization.

• Huffman Desynchronization: Because Huffman codes vary in bit length, a single flipped or missing bit invalidates subsequent symbols. This often causes severe horizontal tearing, color shifts, or scrambled pixel rows starting at the corruption point.
• Restart Markers (RST): If the JPEG was encoded with restart markers, the browser can resynchronize the decoder at designated byte intervals. The decoder drops the corrupted MCU segment and resumes normal rendering at the next intact restart boundary, isolating visual artifacts to a localized stripe.
• Graceful Degradation: Production decoders like libjpeg-turbo are explicitly configured to suppress non-fatal warnings. Rather than throwing an unhandled exception, they decode until a fatal structural break occurs, commit the valid scanlines to the GPU texture memory, and paint the result.

Network Lifecycle and Cache Treatment

The browser's network stack coordinates with the renderer to decide whether a broken image should be accepted or retried.

• Content-Length Mismatch: If the server provided a Content-Length response header and the TCP/TLS connection terminates before reaching that byte count, the browser marks the transfer as an error (ERR_CONTENT_LENGTH_MISMATCH).
• Canvas Paint vs. DOM Event: While the decoder may render partial image data on screen during streaming, the <img> element will not fire a load event if the stream terminates prematurely. Depending on the browser implementation, it may trigger an error event instead, which can cause scripts or CSS fallbacks to hide the element.
• Cache Rejection: Browsers do not store truncated responses in their standard HTTP disk cache as fully valid resources. Incomplete transfers are either purged or marked with range-request metadata, ensuring that subsequent page loads attempt to fetch the complete image rather than repeatedly serving the broken asset.