How to Compress Screenshots Without Blurring the Text

You will finish with screenshots that are a fraction of their original size with no visible softening of interface text. The single decision that matters is format: JPEG is designed for photographs and does the worst possible thing to a screenshot of a user interface.

Before you start

Check what your current images weigh. Open an image-heavy article, open the network panel, reload, and sort by size. A help centre article carrying five uncompressed 2x PNGs often runs to several megabytes, which is slow on a phone and counts against your search ranking.

Genuine JPEG re-encoding at quality 0.3, magnified six times. The haloing is real, not drawn.

Steps

1. Never save a screenshot as JPEG.
   JPEG compresses by discarding high-frequency detail, and the sharp black-on-white edges of text are pure high-frequency detail. It produces visible haloing around every letter and the characteristic smeared look that makes documentation feel cheap.

2. Use PNG for screenshots with flat colour, or WebP for everything.
   Interface screenshots are large areas of flat colour with sharp edges, which is exactly what PNG's lossless compression handles well. WebP does the same job at roughly 25-35% smaller for the same visual result and is supported everywhere that matters now.

3. Reduce the colour palette before compressing.
   A typical interface screenshot uses a few hundred distinct colours, not sixteen million. Quantising to 256 colours with a tool like pngquant typically cuts file size by 60-70% with no visible change on flat interface colours.

   pngquant --quality=70-90 --skip-if-larger --output out.png -- in.png

1. Run a lossless pass afterwards. oxipng -o4 or zopflipng will squeeze a further 10-20% out of an already-quantised file without touching a single pixel value.

   oxipng -o4 --strip safe out.png

1. Resize before you compress, not after.
   Exporting at twice your display width and then compressing beats compressing a huge file and scaling it in the browser. Most of the saving is in not having the pixels at all.

2. Check gradients specifically.
   Palette reduction is invisible on flat interface colours and can produce visible banding on a gradient. If your product has a gradient header, compare before and after at full size.

3. Automate it in the publish path.
   A manual optimisation step gets skipped. Whatever builds or deploys your help centre should run the compression, so the decision is made once rather than per image.

Common mistakes

Using an online "image compressor" that converts to JPEG. Many do this silently. The file gets much smaller and the text gets visibly worse.

Compressing an already-compressed file repeatedly. Lossy steps compound. Keep the original capture and always compress from that.

Optimising the wrong thing. A 400KB screenshot on a page that also loads a 4MB video is not the problem. Measure before optimising.

Stripping all metadata without checking colour profile. Aggressive metadata stripping can remove the ICC profile, which shifts colours on wide-gamut displays. --strip safe keeps it.

Assuming WebP is unsupported. It has been supported by every current browser for years. The fallback complexity most articles describe is no longer necessary.

When this stops scaling

Compression is the most automatable problem in this whole cluster - a build step handles it, and once it exists nobody thinks about it again. If you only do one thing from these guides, put pngquant and oxipng in your publish pipeline.

What does not automate is everything upstream of it. Compression makes a stale screenshot smaller; it does not make it current. It makes an inconsistent set load faster; it does not make it cohere. Optimising a library that nobody is maintaining is a genuine improvement to the wrong variable, and it is a satisfying task precisely because it is tractable in a way the real problem is not.

So: automate this, then look at whether the images are still true. Where documentation images are generated from the product's interface code rather than captured, compression sits in the same pipeline and the currency problem is handled at the same time - a code change produces a new render, already optimised. That is the arrangement SupportPages uses. Compression first though; it is an afternoon and it works.