Private Image Compression Benchmark: Three Real Screenshots

File-size reduction matters only if the output still serves its purpose. Inspect fine text, edges, gradients, faces and transparency before replacing a source file.

Encoding uses browser image codecs. Support and byte output can differ slightly by browser version, which is why the tool verifies the actual returned MIME type and reports the local result.

Interface screenshots contain large flat areas, sharp text and repeated colors. Their compression behavior differs from camera photographs with noise, texture and natural gradients. Mixing both into one average would make the result less useful.

The three inputs were real Windows PNG captures at similar but not identical dimensions. They were not resized, so the measured byte change reflects the chosen output codec and quality rather than fewer pixels.

Each PNG was selected in the release browser, decoded locally and encoded to WebP at quality 82. The output blob had to report image/webp, pass signature detection and return the original width and height on reparse.

We then previewed the result and inspected fine text and edges. No image bytes were posted to an upload endpoint, and the original files remained unchanged.

The 51.6 KiB input became 24.4 KiB, the 42.6 KiB input became 20.5 KiB and the 61.8 KiB input became 31.8 KiB. Reductions were 53%, 52% and 49%, so all three ended near half their source size.

The narrow spread is encouraging for similar interface captures, but a three-file sample is not a universal WebP benchmark. The table displays every input rather than hiding variation behind one headline number.

Zoom into small typography, one-pixel lines, gradients and semi-transparent edges. Compare at the final display size as well as 100%, because defects that are visible under magnification may not matter in normal use—and the reverse can also happen after scaling.

Keep the original PNG when exact lossless pixels or editing are important. Use a converted derivative for delivery, and avoid repeated lossy conversions across multiple editing steps.

Browser encoders and their quality scales can differ by release. PNG input size also depends on how efficiently the source was encoded, so another screenshot can shrink much more or much less.

Test at least a screenshot, a photograph, transparent artwork and a gradient from your own workload. Record browser version, input bytes, dimensions, requested quality, verified output type and a visual decision. Those five facts make the benchmark useful and repeatable.

The benchmark used genuine screenshots supplied during local development. Their pixels could include private interface context, so only dimensions and byte measurements are retained in the public content and implementation report.

That choice reduces perfect reproducibility of the exact bytes but avoids turning user material into a public fixture. Deterministic generated fixtures cover the converter’s validation mechanics, while the real-file sample is clearly labelled as recorded rather than automated.