WebP is so great except it's not (2021)

Original Article ↗ Hacker News Discussion ↗

A photographer’s critique of Google’s WebP image format sparks debate over whether its compression artifacts—especially banding in smooth gradients—make it unsuitable for high‑quality photography, even if many viewers barely notice. Commenters contrast WebP with JPEG, AVIF, and JPEG XL, arguing over trade‑offs between file size, visual fidelity, hardware support, battery life, and backward compatibility. A recurring theme is that automated tooling and Google’s PageSpeed incentives push mass JPEG‑to‑WebP conversion that may degrade important images for modest real‑world gains.

Perceived image quality and banding

  • Thread splits between people who see “no difference at all” and those for whom WebP artifacts are “immediately obvious.”
  • Main complaint: strong posterization / banding in smooth gradients (e.g., portrait backgrounds, vignettes), especially in lossy WebP.
  • Once noticed, some report being “unable to unsee” banding in many WebP images across the web.
  • Others argue that for typical web images (small, busy, or decorative), these artifacts are effectively irrelevant.

Device, display, and viewing conditions

  • Visibility of artifacts is highly device- and context-dependent:
    • Dark rooms and bright, high‑quality or wide‑gamut displays make banding much more obvious.
    • Some see it clearly on old or cheap panels; others hardly at all on laptops or phones.
  • Scaling/resizing matters: inline, downscaled WebP “lossless” previews can show artifacts that the full-size file does not.

Use cases: photographers vs general web

  • Many accept that for professional photography, portfolios, or product shots, WebP’s gradient issues are unacceptable.
  • Others stress “good enough” for the web: for blogs, UI screenshots, thumbnails, etc., WebP’s artifacts rarely matter.
  • Some note the author’s standard is “photographer-high”; web devs often prioritize size, speed, and battery life instead.

JPEG, WebP, AVIF, JPEG XL

  • JPEG:
    • With good encoders (mozjpeg, tuning, dithering), still competitive; often needs only slightly more bytes than WebP for similar perceived quality.
    • Progressive JPEG and mature tooling cited as advantages.
  • WebP:
    • Praised for transparency, animation, and smaller lossless replacement for PNG.
    • Criticized for forced 4:2:0 chroma subsampling, limited-range YCbCr, and poor gradients; often only an incremental win over optimized JPEG.
  • AVIF:
    • Generally viewed as higher quality and more efficient than WebP but computationally heavy; real benefit comes with AV1 hardware decode.
  • JPEG XL (JXL):
    • Strong enthusiasm: better feature set, good quality, fast decoding, and ability to losslessly recompress existing JPEGs ~15–20% smaller.
    • Frustration that Chrome removed support; Safari and Firefox (behind flags) now support it, leading to “Google is blocking the better format” sentiment.

Encoding workflows & technical causes

  • Several point out that re‑encoding already lossy JPEGs to lossy WebP (as many tools and plugins do) is inherently destructive and exacerbates artifacts.
  • Banding linked to:
    • 8‑bit luma precision and aggressive quantization.
    • 4:2:0 chroma subsampling and limited-range YCbCr for WebP.
  • Lossless WebP is generally considered visually identical to PNG and smaller, but easy to misuse when pipelines default to lossy.

Tooling, Google, and standards politics

  • Google PageSpeed and similar tools strongly nudge sites to “convert to WebP,” leading to mass blind recompressions and quality loss.
  • Some see JPEG XL’s treatment by Chrome (dropped as “not enough incremental benefit”) as political/strategic, especially given Google’s own role in JXL research and historical WebP marketing using favorable benchmarks.
  • Others argue Chrome’s removal was about maintenance burden and incomplete implementation, not a conspiracy.

Format support and UX annoyances

  • Complaints about poor OS/app support for WebP (older Windows, some Linux setups, office tools, Slack, GitHub) despite good browser support.
  • Users dislike saving WebP from browsers when everything else in their workflow expects PNG/JPEG; often resort to screenshots or conversions.

Article and site presentation

  • Many find the page hard to read: narrow text column, small font, aggressive discretionary/historical ligatures (“st”, “ct”) called distracting or “trolling.”
  • Some resort to reader mode, custom CSS, or blocking web fonts to make the article legible.