Screenshots are the most common image type on a technical blog, and they're also the most commonly mishandled. Someone drags a raw PNG straight out of the OS screenshot tool into the CMS — full display resolution, no cropping, no compression — and it ships at a file size an order of magnitude larger than the content justifies. Converting to WebP with a deliberate workflow fixes this in under a minute per image.
Why PNG Screenshots Are Oversized by Default
Screen capture tools save PNG because it's lossless and universally supported, not because it's efficient for the web. A full-resolution screenshot from a modern high-DPI display, saved as PNG, encodes every pixel losslessly — including large flat-color regions (browser chrome, whitespace, sidebars) that compress far better under formats designed for photographic and mixed content. WebP's compression, both lossless and lossy, is described in the WebP specification and consistently produces smaller output than PNG for the same visual content, particularly once you allow lossy mode for the non-critical detail.
The Workflow
1. Crop Before You Compress
Never compress the full screen capture. Crop to just the relevant window, panel, or region first — this alone often does more to reduce file size than any compression setting, since you're removing pixels rather than degrading them. Most OS screenshot tools support region capture directly (Cmd+Shift+4 on macOS, the Snipping Tool region mode on Windows); use it instead of capturing the full screen and cropping after.
2. Resize to Publish Dimensions, Not Capture Dimensions
A screenshot captured on a 2x or 3x Retina display is 2-3x the pixel dimensions it needs to be once it's constrained to your blog's content column width (typically 700-900px). Resize down to the actual rendered width before exporting — there's no reason to ship a 2800px-wide image inside a 800px container. The Image Resizer handles this step, and doing it before WebP conversion means the compressor is working on fewer total pixels, compounding the savings.
3. Convert to WebP
Run the cropped, resized PNG through the PNG to WebP converter. For screenshots specifically, the mode choice matters more than for photos:
- Lossless WebP — use for screenshots with small text, code snippets, or sharp UI lines where any artifacting would be visible. Lossless still beats PNG's file size at equivalent fidelity.
- Lossy WebP at quality 85-90 — use for screenshots of visual UI (dashboards, design mockups, marketing pages) where a few soft pixels around gradients or shadows aren't perceptible at normal viewing size. This mode produces meaningfully smaller files than lossless.
If you're scripting this instead of using a UI tool, cwebp exposes both modes directly:
# Lossless — best for text-heavy screenshots
cwebp -lossless -z 9 screenshot.png -o screenshot.webp
# Lossy — best for visual/UI screenshots
cwebp -q 88 screenshot.png -o screenshot.webp
The -z 9 flag maxes out the lossless compression effort; it's slower but doesn't affect output quality, only encode time, and for a one-off blog image the extra second or two of encoding is irrelevant.
Decision Point: Lossless vs Lossy for Screenshots
Default to lossless when the screenshot contains any of:
- Terminal output or code editor content with small monospace text
- Dense UI with thin borders (tables, form grids)
- Diagrams with fine lines or small labels
Default to lossy (quality 85+) when the screenshot is:
- A full-page marketing site or app screenshot dominated by photos, gradients, or large color fields
- Being displayed at a reduced size in the post (any softening becomes imperceptible once scaled down)
- Part of a long series where cumulative page weight matters more than per-image perfection
When in doubt, export both and compare at actual display size — not at 100% zoom, since compression artifacts that are visible zoomed-in are frequently invisible at the width the image will actually render in the post.
Naming and Alt Text While You're There
Since you're already touching the file, don't skip the two things people forget under time pressure:
<img
src="/blog/images/dashboard-settings-panel.webp"
alt="Settings panel showing the new notification preferences toggle"
width="840"
height="472"
loading="lazy"
/>
A descriptive filename and alt text cost nothing extra at this stage and matter for both accessibility and image search — do them at export time rather than as a later cleanup pass that never happens.
Annotating Before You Export, Not After
If a screenshot needs arrows, highlight boxes, or blurred-out sensitive data (API keys, real customer names, internal URLs), do it on the source PNG before converting — not on the WebP. Editing a lossy WebP and re-exporting it introduces a second round of compression on top of the first, the same generation-loss problem that applies to any lossy format. Keep an annotated PNG as your working file, and treat the WebP export as the final, one-way step in the pipeline: crop, resize, annotate, then convert once. If you need to fix a typo in an annotation later, go back to the source PNG and re-export, rather than patching the already-published WebP directly.
Should You Use AVIF Instead of WebP for Screenshots?
AVIF generally compresses better than WebP for photographic content, but for screenshots specifically — dominated by flat color, sharp text, and hard edges rather than continuous tone — the gap between WebP and AVIF narrows considerably, and AVIF's encode time is noticeably longer, which matters more for a batch of blog screenshots than for a one-off hero image. AVIF's browser support is also more recent than WebP's, so a screenshot embedded in an older archived post is slightly more likely to fail to load for a visitor on an older browser. Unless you're already standardized on AVIF sitewide, WebP remains the better default for blog screenshots specifically — the format best suited to text and UI content, with the broadest support, at negligible cost in file size compared to AVIF for this particular content type.
Scripting the Whole Pipeline
For a blog that publishes screenshots frequently, chaining crop, resize, and convert into one repeatable command saves the copy-paste-between-tools tax:
# Crop a fixed region, resize to content width, convert to lossy WebP
convert screenshot.png -crop 1600x900+0+80 +repage -resize 840x cropped.png
cwebp -q 88 cropped.png -o final.webp
rm cropped.png
This is worth setting up once as a shell function or alias if you're publishing more than a couple of screenshots a week — the manual multi-tool workflow above is fine for occasional use but adds friction at volume.
Fallback Considerations
WebP has effectively universal support in current browsers, per caniuse, so a <picture> fallback to PNG/JPEG is rarely necessary for a blog audience today. If your CMS or platform still generates one automatically, that's fine — but manually maintaining a dual-format pipeline for a modern blog is generally unnecessary overhead at this point.
Once you've converted, do a final size check: a cropped, resized, WebP-converted UI screenshot should be visibly and substantially lighter than the original full-screen PNG capture. If it isn't, you likely skipped the crop-and-resize step — compression format matters less than pixel count for screenshots specifically, since so much of a raw capture is dead space the reader never needed in the first place.