Why your screenshots look bad, and how to fix them

Screenshots are the content type most often ruined by a format decision, and the failure has a specific look: text with coloured fringes, smeared button edges, a general muddiness that is hard to name but obvious once you have seen it. The cause is not "low quality settings". It is a design decision inside JPEG that is correct for photographs and wrong for interfaces.

Chroma subsampling, briefly

Human vision resolves brightness far more finely than colour. JPEG exploits this by storing luminance at full resolution and colour information at half resolution or less — typically 4:2:0, meaning colour is sampled at half the width and half the height.

For a photograph this is nearly free. Natural images have soft colour transitions, and halving the colour resolution removes information that the eye was not going to use.

For a screenshot it is destructive. An interface is full of hard, high-contrast, saturated edges: blue links against white, red error text, coloured icons on grey toolbars. Those are exactly the transitions that carry sharp colour information, and subsampling averages them into their neighbours. The result is the coloured halo you see around text in a JPEG screenshot.

Turning the quality slider up reduces the blocking artefacts but does not fix this, because subsampling happens regardless of the quality setting in most encoders.

So use PNG. Usually.

PNG is lossless and does not subsample. Screenshots also happen to be the content PNG compresses best — large runs of identical pixels, limited palettes, hard edges — so the files are often smaller than people expect.

A screenshot of a text editor or a settings panel can compress to a few tens of kilobytes. A screenshot of a page containing a large photograph will not, because now you are storing a photograph losslessly and PNG is bad at that.

That mixed case is where the decision gets interesting.

The mixed-content problem

A screenshot of a webpage with a hero photo is two content types in one file. PNG stores the photo inefficiently; JPEG destroys the text. Neither is right.

Three ways out:

1. Crop. Often the photo is not what you are documenting. Cropping to the interface element in question makes the file smaller, the format decision easy, and the screenshot more useful.
2. Lossless WebP. It handles both content types better than PNG does, typically 20–30% smaller on the same screenshot, with no subsampling.
3. High-quality lossy WebP with subsampling disabled, if your tool exposes that. Rarely worth the complexity for a documentation screenshot.

Capture at the right density

The most common cause of a soft screenshot is not the format at all — it is capturing a high-density display and then serving the result at half size, or capturing a standard display and displaying it at double size.

On a 2× screen, a full-screen capture is twice the logical resolution. Displayed at its logical size in a documentation page, it is crisp. Displayed at its full pixel size, everything looks enormous. Displayed on a 1× screen scaled down, it is fine. Captured on 1× and shown on a 2× screen, it is soft and there is nothing you can do about it afterwards.

The practical rule: capture on the highest-density display available, then set the display width in your page to the logical dimensions and let the browser handle the rest.

Cropping and consistency

For documentation, a set of screenshots that share dimensions and framing reads as considered; a set at fifteen different sizes reads as hurried.

Batch processing helps here in an unglamorous way: capture loosely, then crop the whole set to a consistent aspect ratio and resize to a consistent width. If your documentation column is 800 pixels, exporting everything at 1600 gives you crisp images on high-density screens without wasting bandwidth.

Padding is also useful — a screenshot of a floating panel against a plain background reads better with a few pixels of consistent margin than one cropped tight to the panel edge.

Redaction, done properly

Screenshots leak. Email addresses, account numbers, customer names, internal URLs, the contents of a browser tab bar.

Blurring is not redaction. Pixelation and blur have both been reversed successfully often enough that they should be treated as decoration rather than protection, particularly for short strings like numbers where the search space is small.

Draw a solid opaque rectangle. Then check the exported file, not the editing canvas — flattening is the step where a redaction layer occasionally fails to apply.

A working default

For interface screenshots: PNG, or lossless WebP if your publishing pipeline supports it. Capture at 2×, crop to the relevant region, resize to twice your display width, keep the set consistent.

For screenshots dominated by photographs: crop to what you are actually documenting first, and if you cannot, treat it as a photograph and use a lossy format at high quality.

For anything with sensitive content: solid rectangles, and check the export.