WebP Compress Without Mushy Text — Screenshot Settings
Marketing exports a dashboard PNG, runs it through “compress for web” at quality 60, and the axis labels turn to soup. Photos forgive aggressive lossy settings. Screenshots do not. Text is high-contrast edges; those edges are the first thing cheap codecs smear.
Photos versus UI are different jobs
| Content | Lossy WebP starting point | Notes |
|---|---|---|
| Hero photo | q=60–75 | Softness often acceptable |
| Product shot with label | q=75–85 | Watch small type |
| UI screenshot / docs | q=85–95 or lossless | Prioritize edges |
| Icon / flat graphic | Prefer SVG or lossless | Tiny palette |
One global slider for every asset is how documentation sites get mushy code fonts. Treat compression as a content-type decision, not a single CI constant.
Resize is part of compression
A 2880×1800 Retina capture shown at 720 CSS pixels does not need full resolution. Downscale to about 2× the display size first, then encode. You remove more bytes with resize than with another ten points of quality drop — and text stays cleaner.
capture 2880px → resize 1440px → WebP q=88 → often smaller AND sharper than
capture 2880px → WebP q=55Crop to the relevant panel before either step. Fewer pixels beat cleverer quantizers when the subject is a settings modal.
Lossless and near-lossless
WebP supports lossless. For documentation, changelog GIFs of UI, or any frame where a single blurred pixel causes support tickets, lossless (or PNG) is rational. Measure lossy q=90 versus lossless size; if lossless is only slightly larger, ship lossless for that asset class. Do not force lossless on a 4K photo background.
Chroma subsampling that is invisible on skies softens colored badges and red error text. If your encoder exposes chroma settings, be conservative on screenshots. Preview at 100% zoom on a paragraph of UI type — never judge sharpness from a thumbnail of the wallpaper.
Local workflow that does not leak assets
- Crop to the relevant panel.
- Resize to max display needs.
- Encode WebP at high quality; compare with PNG.
- Spot-check at 100% zoom on text, not on the wallpaper.
- Keep the original PNG in design source control; commit the compressed derivative for the site.
Use a browser image compress tool so sample assets never upload to a random third party during experiments. Automate the winning settings in CI (Sharp, Squoosh CLI, and similar) once humans agree on the preview.
Delivery tips that preserve sharpness
- Serve width-appropriate
srcset— do not rely on CSS shrink alone - Use
image-renderingonly for true pixel art; it will not fix muddy WebP - Avoid re-encoding already compressed screenshots five times in the pipeline
- For mixed pages, different qualities per class beat one global knob
- Prefer SVG for icons and simple diagrams instead of rasterizing UI chrome
Animated UI is a separate trap: animated WebP or short video can still mush text frames. Test a mid-animation frame at full zoom before celebrating the file size.
Decision cheat sheet
- Body photography → aggressive lossy OK
- Marketing UI shot → high-q WebP or lossless
- Tiny icon → SVG/PNG
- Dense terminal or code screenshot → bias lossless
- Hero that mixes photo and overlaid UI → split layers when possible
Compression is not a morality play about “always smaller.” Treat screenshots like text documents that happen to be bitmaps: resize thoughtfully, keep quality high, and only then celebrate the smaller file size. Your readers notice mushy labels long before they notice you saved forty kilobytes.
Preview like a reader, not like a gallery
Judge screenshot compression at 100% zoom on a paragraph of UI text and on a table of numbers — not on the blurred backdrop. Flip between PNG and WebP in a flick; if you need to squint, raise quality or switch to lossless for that asset class. Keep originals in design storage and only commit derived web assets so you can recompress when codecs improve. Document the chosen quality per content class in the repo so the next intern does not rediscover that q=60 ruins UI.