Skip to content

image guide

Screenshots: The Best Format, the 10x Size Fix, and Keeping Text Sharp

A retina screenshot is a pathological file: the biggest image most people produce (a 5K display capture is 60+ megapixels), full of the exact content — sharp text edges, flat colour regions — that JPEG handles worst and PNG handles best-but-bulkiest. Which makes screenshots the single highest-leverage optimisation target for bug reports, docs, tickets and blog posts: usually 5-15 MB to 100-300 KB with zero legibility loss, if you pick the right format and optionally the right dimensions. This guide is the recipe.

Updated September 22, 2026 · 12 questions answered

Key takeaways

  • JPEG is the wrong format for screenshots: its chroma subsampling smears text edges and flat-colour banding shows at every boundary — PNG or WebP always.
  • A PNG screenshot can drop 60-80% of its weight from lossless optimisation alone — no pixels touched, no quality lost.
  • Retina 2x screenshots are display-resolution overkill: downsample to the width the reader actually sees (usually half), which cuts file size about 4x with a quality gain on non-retina screens.
  • For text-heavy captures destined for the web, lossy WebP at 85-90 is often visually identical to the PNG at a tenth of the bytes; check tiny text at 100% before trusting it.
  • Crop before compressing: the 400 px of desktop around the dialog is 30% of the bytes and 0% of the message.

Why Screenshots Break the Normal Advice

Photographs are smooth gradients; screens are brutal discontinuities — black text on white at 10 px, 1 px borders, hard colour changes every few pixels. JPEG's whole design is discarding information the eye forgives in smooth content, and a screenshot contains none of the forgiving content: the ringing around every glyph, the banding in the flat panels, the smeared anti-aliasing on the borders. The same image as PNG is exact, and as lossy WebP at 90 is visually exact at a tenth of the size (the image file size guide has the per-destination budgets).

Retina capture doubles the problem: a 2x screenshot of a 1440 px window is a 2880 px file with text strokes two pixels thick, and it displays on most readers' screens at a size where half of those pixels are resampled away by software with cheaper algorithms than your downscale would have used.

The Recipe for Every Destination

Ticket or email attachment: crop to the content, downscale to the actual display width (usually 50% of a retina capture) with the resizer, export PNG. The typical result is 200-600 KB where the original was 8 MB, and text stays pin-sharp because PNG stores exactly what it is told.

Blog post or documentation: same crop and downscale, then the compressor at lossy WebP quality 85-90. UI screenshots are WebP's best case — flat areas compress to almost nothing and the only cost is on text edges, which the quality-85 band preserves visually. Verify the smallest text in the capture at 100% zoom before shipping, and fall back to PNG if the design has 9 px captions.

Sending to someone who will zoom: keep PNG at native resolution and compress losslessly (the optimisation pass removes PNG's waste — redundant filter choices, oversized palettes — without losing one pixel). A 6 MB retina PNG lands at 1.5-2.5 MB fully exact; that is the version for evidence, review and annotation.

The Annotator's Note: Crop First

The free win nobody does: a 2880 × 1800 retina capture of a 600 × 400 dialog is 95% background. Cropping to the subject multiplies every subsequent compression's effect and, more practically, focuses the reader's eye where the bug is. The ticket-quality test: open the image at 100% and ask whether the text you are reporting is already readable — if yes, everything outside it is padding; cut it.

Where the context matters (the menu path, the URL bar proving the environment), crop to the minimum frame that keeps the evidence rather than the whole desktop. And for anything public, redaction discipline first: faces, usernames and account numbers get pixelated — genuinely destroyed, not gently blurred — before sending, because weak blur is reconstructable.

Formats, Once and for All

PNG: always correct, sometimes fat. The safe answer when the receiver might zoom, edit or print. Lossless optimisation is free — run it always.

WebP: the delivery format for the web; lossy 85-90 handles most UI, lossless beats PNG by 15-30% and keeps exact pixels for the designs with hairlines.

JPEG: never, for text — the one exception being a screenshot of a photograph (the Netflix thumbnail bug), where the content is photographic and the format logic follows.

AVIF: excellent compression and growing support; for screenshots the win over WebP is smaller than the WebP win over PNG, because flat-colour content is cheap in both — use it for docs sites and tickets only if the viewer matrix supports it.

Frequently asked questions

The questions people ask most about how to compress and resize screenshots without losing legibility, answered directly.

Why is my screenshot file so big?

Because retina displays capture 2-4x the pixels of what you see, and PNG stores them honestly — a full-screen MacBook screenshot is 5K × 3K, 15+ megapixels. The fix is a crop to the content and a 50% downscale, then lossless PNG optimisation; an 8 MB capture routinely lands under 500 KB with no visible loss.

What is the best format for screenshots?

PNG for anything that must stay exact (tickets, zooming, editing); WebP for anything displayed on the web — 70-90% smaller than the PNG at visually identical quality for UI content. JPEG never: it smears exactly what screenshots are made of, which is text edges and flat boundaries.

How do I compress a screenshot without losing text quality?

Downscale to the real display width first, then lossy WebP at quality 85-90, or lossless WebP/PNG optimisation if the receiver will zoom. Check the smallest text at 100% — if it is clean, the compression is done; screenshots compress dramatically better than photos at the same perceived quality.

Should screenshots be 1x or 2x for a website?

Serve 1x for normal documentation and 2x only where the audience skews retina and detail matters (developer docs, design specs). A 2x WebP screenshot is 3-4x the bytes for sharpness most readers cannot perceive through the site's own layout scaling.

Why does my screenshot text look blurry online?

One of three: JPEG compression ringing around the glyphs, the platform resizing the oversized capture with a cheap filter, or a 2x image being downscaled to 1x by the browser. Fixes in order: leave JPEG alone, resize to display width yourself, serve the correctly-sized file.

How do I reduce screenshot size for email?

Crop, downscale to about 1400-1600 px wide, PNG. The result is 200-500 KB and every UI string stays readable, which is the whole job of a screenshot in a thread. A 6 MB original is neither polite to the list nor useful to the reader.

How do I make a screenshot smaller for a form upload?

The 2 MB rejection path: crop to content, resize to the stated dimensions if any, then compress — PNG optimisation for exactness or WebP for size. Verify the file's new weight before uploading; a form that says 2 MB rejects 2.04 MB, and half a megabyte of margin is free insurance.

Is WebP lossless as good as PNG for screenshots?

Better — same pixels, 15-30% smaller, because WebP's predictive coding models flat UI regions more cleverly than PNG's DEFLATE. The only reason PNG remains the default: universal decoder support and the expectation that a .png is exact.

How do I blur my screenshot before sending?

Decide first whether it is decorative blur (a background in a mockup) or redaction (faces, keys, account numbers). Redaction needs pixel destruction — hard pixelation or an opaque cover — because a light blur is reconstructable; pixelate the sensitive region before sending.

Do screenshots keep metadata like photos?

Almost none — capture tools write minimal metadata and no GPS — which makes them the safe format for sharing and the inconvenient one for proof-of-capture, since they carry no timestamp beyond the file system's modification date.

What size should a bug-report screenshot be?

Whatever resolution shows the bug at 100% zoom without scrolling — usually a 1200-1600 px wide PNG, 200-600 KB. A full-desktop 5K capture makes the developer hunt for the region; a cropped, downscaled, sharp-text capture makes the bug obvious in the thumbnail.

Can the tools compress screenshots without uploading?

Yes — crop, resize and compress all run in the browser tab, which matters for the screenshots that show internal systems, private URLs and colleague names. The capture never leaves the machine; the Network tab proves it.