That distinction matters when an infographic contains labels rather than just a photograph. Our earlier discussion of content infrastructure recommends modern image formats broadly. Here we tested a specific export problem: how much of a small label survives a deliberately tight file budget.

Three graphics, one file limit

The inputs were existing PolymathDesk editorial graphics: an employer-housing flow, a tunnel-toll diagram and a hobby-licensing diagram. They combine small coloured labels with illustration and texture. We used their generated PNG masters, flattened them onto white, converted them to sRGB and resized each once to 600 × 900 pixels. That resized raster was the reference for every subsequent encode.

For each image, we encoded all 100 integer quality settings from 1 to 100 in three configurations. Both JPEG variants used mozjpeg; one used 4:2:0 colour subsampling and the other 4:4:4. WebP used effort 6 and smart subsampling. For each configuration we selected the highest quality setting that stayed within 32,768 bytes. The resulting files ranged from 32,024 to 32,736 bytes.

Before encoding, we selected one rectangle containing a small label in each reference. We measured the root mean square difference between decoded red, green and blue channel values and the reference on the 0–255 scale, both across the whole image and inside that rectangle. Lower RGB RMSE means closer pixels. It does not measure reading speed or prove that a word is legible. This is a three-image convenience sample, not a representative benchmark; we did not test AVIF, OCR, human readers, high-density displays or page-loading performance.

The selected-label RGB errors under the 32 KiB limit were:

  • Housing — JPEG 4:2:0 15.47; JPEG 4:4:4 14.10; WebP 8.36.
  • Tolls — JPEG 4:2:0 15.55; JPEG 4:4:4 15.48; WebP 9.16.
  • Licensing — JPEG 4:2:0 10.37; JPEG 4:4:4 11.36; WebP 4.17.

WebP also had the lowest whole-image error in all three cases. Within JPEG, however, the label and whole-image results differed. The 4:4:4 version slightly improved the housing and toll labels, while increasing whole-image error in every file. In the licensing label it increased both. Extra colour detail had a cost elsewhere in the encoding.

Actual housing-label pixels from the reference PNG, JPEG 4:2:0, JPEG 4:4:4 and WebP, enlarged equally. Both JPEG crops show visible block patterns around the white word Priority on red.
The same 110 × 45 pixel region from each decoded housing image, enlarged 4× with nearest-neighbour scaling. These are actual test pixels, not generated examples. The compression limit applies to each complete 600 × 900 image, not this crop.

More colour detail costs bytes

JPEG 4:2:0 keeps colour information at a lower spatial resolution than brightness information. The 4:4:4 setting retains colour samples at full resolution. Sharp exposes both settings; changing the quality number is a separate operation. Small coloured edges are a useful place to examine the difference.

We therefore made a second comparison at JPEG quality 95, without the 32 KiB restriction. On the housing label, 4:4:4 reduced RGB RMSE from 8.42 to 2.82. The complete file grew from 114,051 to 149,606 bytes. It also reduced label error in the toll and licensing graphics. At that setting, preserving colour detail had a clear measured benefit.

Under the byte cap, the encoder had to make a different tradeoff. The housing image fitted at quality 41 in 4:2:0, but only quality 28 in 4:4:4. For the licensing image the settings were 67 and 51. Keeping more colour samples left less room for other detail. Selecting 4:4:4 alone could not guarantee a better label within this budget.

We enabled WebP’s sharper RGB-to-YUV conversion; Google documents that operation in the cwebp encoder’s sharp_yuv option.

The cost of keeping every pixel

Lossless WebP preserved every RGB value of all three resized references, confirmed by comparing their decoded buffers. Its files were 299,522, 347,556 and 348,212 bytes. The corresponding full-colour PNG references were 415,385, 461,372 and 452,638 bytes, using Sharp’s compression level 9 and adaptive filtering. We did not run an exhaustive PNG-optimiser comparison.

These lossless files were much larger than the 32 KiB cap, but they answer a different publishing need: preserving a raster label exactly. Lossless and lossy WebP are distinct encoding modes. Our separate PNG experiment about hidden colours under transparency concerns another part of image handling; opacity and file type alone do not describe what an export preserves.

For these three graphics, lossy WebP was the strongest measured option at the chosen cap. A publisher who needs identical label pixels would instead have to allow a larger lossless file, simplify the graphic, or keep essential wording as HTML text. The original master should remain available for future exports.

Test run on 5 October 2026 using Sharp 0.35.4, libvips 8.18.6 and libwebp 1.6.0. File sizes, highest-fitting quality choices and RGB-error arithmetic were independently checked in Python using retained decoded buffers. The cover is a generated visual concept; the comparison inside the article contains actual decoded test pixels.