Chrome's JPEG Optimization: Why Tiny Images Look Different
Original: Why tiny JPEGs look different in Chrome
Why This Matters
Reveals how browser-level media decoding optimizations silently affect visual fidelity at small image sizes.
A developer investigating a rendering discrepancy between Chrome and Firefox discovered that Chrome uses a JPEG decoding optimization called 1/8-scale DCT decoding. When a JPEG is displayed at very small sizes, Chrome skips full decompression and decodes only low-frequency DCT coefficients, producing a visually different—but computationally cheaper—result.
Engineer Guillaume Técher noticed that a logo rendered at 15px appeared visually different between Firefox and Chrome. After investigation, he identified a deliberate JPEG decoding optimization in Chrome. Standard JPEG decoding decompresses the full image into memory before scaling it down. For a 2000×2000 JPEG displayed at 20×20, that means allocating roughly 12 MB for a result that requires only ~1.2 KB. Chrome avoids this by exploiting the JPEG format's internal structure. JPEG splits image data into 8×8 pixel blocks and applies a Discrete Cosine Transform (DCT), separating image content into frequency components—from flat color (low frequency) to checkerboard-like detail (high frequency). When an image is rendered at 1/8 of its original size, each 8×8 block maps to approximately one pixel. At that scale, high-frequency detail is largely irrelevant to the final appearance. Chrome therefore decodes only the low-frequency DCT coefficients—skipping the high-frequency ones entirely—reducing memory usage and computational cost significantly. This is the root cause of the visual difference: the two browsers are not rendering a bug, but rather applying different decoding strategies. Swapping the JPEG for an SVG eliminates the discrepancy entirely.