{"id":14888,"date":"2026-10-28T07:35:00","date_gmt":"2026-10-28T06:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=14888"},"modified":"2026-10-26T13:11:17","modified_gmt":"2026-10-26T12:11:17","slug":"webp-file-sizes-comparing-light-and-dark-diagrams-fairly","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/webp-file-sizes-comparing-light-and-dark-diagrams-fairly\/","title":{"rendered":"WebP File Sizes: Comparing Light and Dark Diagrams Fairly"},"content":{"rendered":"

A light diagram can produce a larger file than a dark version. That observation alone does not explain the cause. Image content, encoder version, lossless or lossy mode, quality, metadata and preprocessing can all affect the result. A useful comparison separates file size from the explanation for that size.<\/p>\n

What the historical comparison can establish<\/h2>\n

The original workshop account reported 662 pairs and totals of 32.5 versus 56.2 MB. Those totals imply approximately 73% more bytes for the light set. If the measurements were recorded correctly, the byte difference was real; the unsupported step was attributing the difference to brightness alone.<\/p>\n

The complete original measurement table, sample selection and encoder settings could not be recovered during this review. The old factors are therefore not presented as a newly verified benchmark. In particular, a wide spread does not disprove a brightness effect, and a mean above the median does not establish that only a few outliers caused the difference.<\/p>\n

\"New
New measurement, 25 October 2026: twelve deliberately selected diagram pairs, identical encoding settings within each mode. This is a sample result, not a universal brightness rule.<\/figcaption><\/figure>\n

A fresh comparison with recorded settings<\/h2>\n

The new check used twelve existing English diagram topics, each in dark and light form: 24 RGB PNG files, all 2240 \u00d7 1160 pixels. The topics were selected deliberately, not randomly. Private copies were encoded with Pillow 11.1.0 and libwebp 1.5.0, without resizing or copying metadata.<\/p>\n

Each file was encoded twice: lossy WebP at quality 90 and method 6, and lossless WebP at quality 90 and method 6. In lossless mode, the quality parameter controls compression effort rather than permitted image degradation. The two modes are therefore separate comparisons.<\/p>\n\n\n\n\n\n\n
Mode<\/th>\nMedian light\/dark ratio<\/th>\nRange<\/th>\n<\/tr>\n<\/thead>\n
Lossless<\/td>\n1.000<\/td>\n0.965\u20131.027<\/td>\n<\/tr>\n
Lossy, quality 90<\/td>\n0.974<\/td>\n0.952\u20131.010<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Within this sample, the two themes had similar sizes. Lossless was smaller than lossy quality 90 for all 24 files. For each file, the lossy size was divided by the lossless size. The middle of the sorted ratios, called the median, was 1.577: this ratio corresponds to about 58% more bytes for lossy encoding. Decoding the lossless outputs reproduced every source pixel exactly. This supports testing lossless for these diagrams; it does not prove that lossless always wins for graphics or that light and dark images always weigh the same.<\/p>\n

Why palette and RGB are not the whole explanation<\/h2>\n

A PNG palette describes how source colors are stored. It does not force a particular WebP compression mode. A pipeline can decode both palette and RGB sources to the same pixels before encoding. The PNG IHDR color type is useful evidence about the source, but encoder logs are needed to establish what happened next.<\/p>\n

Lossy WebP predicts pixel blocks from neighboring pixels. It transforms the differences between prediction and source, then rounds the resulting values to save space; this rounding loses information. Flat areas can compress efficiently too. Lossless WebP uses different transforms and coding techniques, including palette-related techniques. \u201cQuality 90 wastes bits in every flat area\u201d is therefore not a sound explanation.<\/p>\n

A smaller result still needs a quality check<\/h2>\n

A re-encoded source that is four times larger than an existing file is a reason to inspect the pipeline. It does not uniquely identify a changed quality setting. Codec versions, metadata, pixel conversion and compression mode can also differ. Conversely, similar byte counts do not prove identical settings.<\/p>\n

For a fair experiment, the original PNG is the input for both modes. Re-encoding an already lossy WebP in lossy mode can discard more image details. A comparison should record input hashes, dimensions, transparency, versions, explicit options, output bytes and decoded image quality. Thin text and colored edges deserve a visual check.<\/p>\n

\n

Questions and answers<\/h2>\n

Does 27 larger files out of 40 mean a coin-toss result?<\/h3>\n

No: 27\/40 is 67.5%. The count alone neither proves equal sizes nor measures the size difference. Related diagram templates also undermine an assumption of independent observations. Ratios and the selection method are more informative than that analogy.<\/p>\n

How is WebP compression mode identified?<\/h3>\n

The image payload uses VP8 <\/code> for lossy coding or VP8L<\/code> for lossless coding. VP8X<\/code> describes an extended container; metadata, alpha or animation chunks may occur before the image data. A full inspection with webpinfo<\/code> is safer than reading only the first chunk.<\/p>\n

Can the original quality setting be recovered?<\/h3>\n

WebP has no standard field storing the encoder’s original quality option. Re-encoding with known settings can provide comparisons, but cannot uniquely recover all original choices. Encoder logs are the stronger evidence.<\/p>\n

Does the result apply to photographs?<\/h3>\n

No general result follows from this diagram sample. Lossy encoding often saves substantial space for textured images at acceptable visual quality. The choice depends on the actual image and the required quality, not only on its category.<\/p>\n<\/div>\n

\n

Sources<\/h2>\n