Why tiny JPEGs look different in Chrome
Points and comments are a snapshot, not live.
Chrome's JPEG decoder uses partial frequency data to save memory, altering small images.
A Chrome rendering difference traces to Skia's use of partial IDCT scaling in libjpeg-turbo. When displaying a JPEG at a fraction of 8, Chrome decodes only low-frequency DCT coefficients, skipping high-frequency detail that would be lost in downscaling anyway. This avoids fully decompressing the 2000×2000 source into a 12 MB bitmap for a 1.2 KB 20×20 output. The technique, called partial IDCT scaling, works for any denominator-of-8 fraction. The author notes the resulting degradation is a mix of IDCT and scaling algorithm, and recommends avoiding JPEG for icons.
What commenters are saying
Commenters largely agree the effect is a combination of partial IDCT and different scaling algorithms (Chrome blurrier, Firefox sharper with ringing). Firefox uses downscale-during-decode rather than Skia's approach. A Mozilla bug (2033250) tracks implementing similar partial decoding. Memory savings aren't the goal; speed and cache are. Several commenters note real-world problems: Chrome's optimization broke PNG-based icons in Electron apps, and IDCT scaling can expose garbage in trailing MCU rows/columns from flawed encoders (crbug.com/890745).