WebP Export Settings — When Quality 80 Looks Worse Than JPEG
Shipped WebP because Lighthouse said so. Hero image looks mushy on retina. Designer says “just use PNG.” You re-export at quality 100 and file size is bigger than the original JPEG. r/webdev argument ensues — nobody measured at actual display dimensions or picked the right lossy vs lossless mode.
- Same quality number across codecs — WebP Q80 ≠ JPEG Q80. Compare visually or by file size at fixed SSIM, not slider position.
- Lossy WebP for UI screenshots — Text and flat colors ring and blur; lossless WebP or PNG wins.
- Converting JPEG → WebP → JPEG — Generation loss stacks. Keep master in lossless format.
- Ignoring alpha — WebP alpha is lossy in lossy mode; halos around icons are a codec + export setting issue.
Lossy vs lossless decision
| Content type | Recommended |
|---|---|
| Photos, gradients | Lossy WebP ~75–85 |
| Icons, logos, text UI | Lossless WebP or SVG |
| Photos with transparency | Lossy WebP + check alpha edges |
| Animation | WebP lossy animation vs video (AV1/WebM) tradeoff |
Quality slider starting points
These are starting points — always A/B at 1× and 2× display width:
| Use case | Lossy quality | Notes |
|---|---|---|
| Blog hero 1200w | 80–85 | Check skin tones and sky banding |
| Product grid thumbs | 75–80 | Smaller display forgives more |
| Full-bleed photo bg | 82–88 | Banding in gradients shows first |
| OG / social card | 85–90 | Text overlay needs sharp base |
cwebp CLI example:
cwebp -q 82 photo.jpg -o photo.webp
cwebp -lossless icon.png -o icon.webpWhy it “looks worse”
- Viewing at wrong size — 4000px export displayed at 400px hides artifacts; opposite also true — upscaling soft WebP looks terrible.
- Sharpening in JPEG source — WebP recompression eats artificial sharpening halos.
- 4:2:0 chroma subsampling — Same as JPEG; red text on blue background bleeds.
- Near-lossless misunderstood —
-near_losslessin cwebp is not magic; still inspect edges.
AVIF vs WebP in 2026
AVIF often beats WebP size at same quality on photos; encode CPU cost is higher. Practical stack:
<picture>with AVIF → WebP → JPEG/PNG fallback- Generate derivatives at display widths (640, 960, 1280), not one 4000px master for all
Workflow with compress tool
- Export master from design tool (avoid double JPEG).
- Resize to max deployed width before compress.
- Try lossy WebP at 80 — compare side-by-side with original at 100% display zoom.
- If edges matter, switch lossless or keep PNG for that asset only.
- Run image compress tool locally — batch compare sizes.
Lighthouse vs aesthetics
LCP wants bytes down; brand wants crisp hero. Negotiate: maybe hero is slightly larger WebP, thumbnails aggressive. One global Q60 policy fails both metrics and design review.
CDN and cache invalidation
After re-exporting WebP at higher quality, CDN cache may serve old blurry derivatives for days. Purge by URL or version query (hero.webp?v=2) when comparing before/after — otherwise design review argues against a fix users never receive.
Animated WebP gotcha
Animated WebP uses lossy frames independently — banding in gradients animates visibly. For subtle loop backgrounds, test on OLED at low brightness; compression artifacts that pass on LCD posterize on dark UI themes.
Tool: compress and compare
The image-compress tool converts and compresses in-browser — quick before/after without uploading client assets to unknown servers.
TL;DR
WebP quality numbers aren’t portable across formats. Photos → lossy ~80; UI/text → lossless or PNG. Resize to deployed width, compare at real display size, use <picture> fallbacks.