How to Compress Screenshots Without Blurry Text
Compress screenshots without fuzzy text: keep a PNG master, resize first, export WebP when accepted, and check the result at 100%.
Contents
Screenshot compression is different from photo compression: keep a PNG master, resize the image to the size where it will be shown, then export a smaller WebP copy if the site or app accepts it. Avoid JPEG for UI screenshots with small text. It often blurs the letters before the file gets meaningfully smaller.
Everyone’s been here: you capture a clean settings screen, paste it into a WordPress post or support doc, and the sidebar labels suddenly look like wet ink. I ran a 1600 x 900 documentation-style screenshot for this post: the original PNG was 86,540 bytes, lossless WebP was 40,562 bytes, WebP at quality 85 was 39,224 bytes, and JPEG at quality 82 was 92,185 bytes. Weird result. Useful result.
Start with the native screenshot file, not a JPEG
Start with the file your device captures by default. macOS Screenshot, Windows Snipping Tool, iPhone screenshots, and Android screenshots usually give you a PNG, which is exactly what UI text wants because the letter edges stay crisp.
The catch is that the native file can be heavier than you want. Do not fix that by opening the screenshot in a photo editor and saving a JPEG copy. Squarespace’s own image guidance says images containing text should be saved as PNG, and that text in JPG files often becomes blurry when compressed.
Keep the PNG as your master. That’s the file you return to if the exported version gets soft, if the CMS recompresses it, or if a support teammate asks for a bigger version next week. Almost. Except you do not need to upload that master everywhere.
If the screenshot is a transparent PNG from a design comp or product mockup, the advice overlaps with our guide on how to make a PNG smaller without losing the alpha channel.
Resize to the display size before you compress
Resize the screenshot before compression if the final page only shows it at a smaller width. A 1600 px screenshot displayed at 800 px wastes bytes, and the browser or CMS still has to resample the grid, type, and UI chrome.
This is where screenshots punish lazy exports. Photos can hide a little softness in texture. UI screenshots have table borders, icons, anti-aliased labels, and gray text on pale backgrounds, so a bad resize shows up immediately at 100% zoom.
For blog documentation, I usually capture wide enough for the interface to make sense, then resize once. Not twice. If you resize in Preview, then WordPress scales it again in the layout, you are stacking interpolation on top of compression. The screenshot may still load, but the weight and contrast both take a hit.
Use a browser-based image resizer when you need an exact width, such as 1200 px for a help-center article or 800 px for an inline tutorial image. RoundCut is handy here because it keeps the screenshot in your browser, but it will not fix a screenshot that was already blurred by a CMS.
Use lossless WebP when the upload target accepts it
Use WebP for the upload copy when your target accepts it, especially for web articles, product docs, and knowledge-base pages. Google’s WebP docs report lossless WebP files at 26% smaller than PNG on average, while lossy WebP can beat JPEG by 25-34% at comparable quality.
My local test was better than that average: lossless WebP cut the PNG by about 53%, from 86,540 bytes to 40,562 bytes. I wouldn’t promise that on every screenshot. A flat UI with repeated colors compresses beautifully; a dense dashboard with thumbnails, gradients, and avatars will not shrink as cleanly.
For screenshots with text, start with lossless WebP or a very high-quality lossy WebP. Then check the result at 100% zoom. If the small labels stay sharp, you’re done. If they shimmer, back off the compression or keep the PNG.
When the platform accepts WebP, convert the upload copy with PNG to WebP. If the platform rejects WebP, stay with optimized PNG rather than forcing JPEG just to chase a smaller number.
Check the app that will receive the screenshot
Check the destination before you compress too hard. WordPress upload limits vary by server, Office can compress pictures inside documents, Outlook can resize attached images, and some older CMS fields still reject WebP even when the public website supports it.
WordPress Site Health exposes the max upload size and the supported media formats for the server. That matters because one WordPress site may accept WebP and a 64 MB upload, while another blocks the same file at 2 MB. Same dashboard. Different plumbing.
Office has its own trap. Microsoft documents settings to turn off picture compression inside Office files and to avoid resizing attached images in Outlook, which tells you the bigger point: your clean export can still be changed after you insert it into the document (which is why the final check matters).
If you are chasing a strict upload cap, use the same approach as a normal photo workflow: resize first, then compress, then check readability. Our compress to 2MB guide covers the size-cap logic, but screenshots need a tougher eye on text.
What file size should a screenshot be?
A screenshot for a blog post or help doc should usually land between 40 KB and 300 KB after resizing, but the right size depends on detail. A clean settings screen can be tiny; a full analytics dashboard may need more room.
Here’s the quick decision table I use (the boring version that catches most mistakes):
| Screenshot type | Keep as | Try next | Watch for |
|---|---|---|---|
| UI with small text | PNG master | Lossless WebP | Blurry labels |
| Help-center step | PNG master | WebP q85-95 | Soft icons |
| App screenshot for email | PNG or WebP | Smaller PNG | Outlook resize |
| Photo-heavy dashboard | WebP | JPEG only if needed | Muddy thumbnails |
Small enough is the goal. Not smallest.
The format choice also depends on the image itself, so do not treat this as a religious PNG-vs-WebP fight. If you need a broader refresher, this RoundCut format guide lays out where PNG, JPEG, and WebP each make sense.
For website performance work, read the screenshot next to the rest of the page. A 280 KB screenshot may be fine inside one tutorial; ten of them on a landing page will drag. The deeper WebP vs JPEG trade-off is about total page weight, not one perfect export.
Compress the final copy, then inspect it at 100%
Compress the copy you plan to upload, not the master. Drop the resized PNG into RoundCut Compress, export WebP or a smaller PNG, and open the result at actual size before it goes into WordPress, Notion, Zendesk, Gmail, or Outlook.
I look at three spots: small sidebar labels, thin table borders, and gray helper text. If those survive, the screenshot will usually survive the post. If they do not, no amount of alt text or layout polish will make the image feel sharp.
RoundCut’s downside is simple: it works on the file you give it. It does not rewrite images already inside WordPress, it can’t stop Office from recompressing an inserted picture, and it will not rescue a screenshot that was captured too small in the first place.
Next screenshot, do the boring version. Capture PNG, resize once, export a WebP copy if the destination accepts it, and check the letters at 100%. Thirty seconds. Cheaper than republishing a fuzzy help article.
