The short answer: for a screenshot that needs to be smaller than its PNG, WebP is the safest choice. Our PNG to WebP converter made every one of our 20 screenshots smaller, at a median 39% of the PNG's size, and kept the text sharpest of the lossy options (median SSIM 0.998). JPG is the format that catches people out: at our default 85% quality it was a median 72% of the PNG, but on 4 of the 20, all with large flat areas and small text, the JPG was bigger than the PNG, by up to 39%. On pages that contain photos, both lossy formats shrink the file a lot. And if the screenshot must stay pixel-exact, keep the PNG: re-saving it barely changed the size, and lossless WebP, which halves it, is not something our tools make.
What we did
We took 20 screenshots with a script: 12 desktop screenshots of a 1440 × 900 window at 2× pixel density (saved at 2,880 × 1,800 pixels, as on a Retina Mac), and 8 phone screenshots of a 390 × 844 screen at 3× density (1,170 × 2,532 pixels, an iPhone-sized screen). The pages were Wikipedia articles, US government sites (NASA, the National Weather Service, USA.gov), the Python and MDN documentation, and four pages we built ourselves: a code editor with syntax colours, a spreadsheet, a light chart page and a dark analytics dashboard. We sorted them into four groups by what dominates the screen: text, flat-colour interface, photos and dark mode.
Each PNG then went through three Pixohub tools at their default settings: PNG to JPG (85% quality), PNG to WebP (85% quality) and Compress Image (a JPG at 70% quality). Pixohub has no PNG optimiser and no lossless WebP option, so for comparison we also re-saved each PNG with maximum zlib compression in Pillow and made a lossless WebP with Google's cwebp command-line tool.
Results across all 20 screenshots
| Output | Median size vs PNG (range) | Bigger than the PNG | Median SSIM (lowest) | Text-edge PSNR |
|---|---|---|---|---|
| Original PNG | 530 KB (138 KB–3.2 MB) | – | 1 (identical) | – |
| PNG re-saved, max compression (Pillow) | 99% (94–107%) | 8 of 20 | 1 (identical) | – |
| Lossless WebP (cwebp, not a Pixohub tool) | 51% (22–73%) | 0 of 20 | 1 (identical) | – |
| PNG to WebP, 85% | 39% (7–71%) | 0 of 20 | 0.9979 (0.9918) | 33.0 dB |
| PNG to JPG, 85% | 72% (14–139%) | 4 of 20 | 0.9947 (0.9879) | 31.3 dB |
| Compress Image, JPG 70% | 54% (10–107%) | 1 of 20 | 0.9884 (0.9700) | 28.6 dB |
Three things stand out. First, the screenshot PNGs were already well compressed: re-saving them at maximum compression saved a median 0.6% and made 8 of the 20 slightly larger. A PNG optimiser of the usual kind would not have changed the picture much. Second, WebP beat JPG on both counts at once: smaller files and higher fidelity, on every screenshot. The WebP was smaller than the JPG on all 20 and scored a higher SSIM on 19; the exception was the NASA home page, where the two were within 0.0005 of each other. Third, the files our converters wrote kept the full resolution and an sRGB colour profile; nothing was scaled down.
By type of screenshot
| Group | PNG (median) | JPG 85% | WebP 85% | Lossless WebP | Compress (JPG 70%) |
|---|---|---|---|---|---|
| Text-heavy (3) | 530 KB | 73% | 44% | 47% | 55% |
| Flat-colour interface (6) | 431 KB | 77% (37–139%) | 39% | 58% (22–65%) | 59% |
| Contains photos (4) | 1,385 KB | 37% | 21% | 64% | 27% |
| Dark mode (7) | 410 KB | 89% (49–107%) | 44% | 43% | 67% |
Text and flat interfaces
Text on a plain background is where PNG is at its best and JPG at its worst. PNG compresses long runs of identical pixels very well, while JPG spends bytes on every sharp edge, and a page of small text is almost all sharp edges. Our spreadsheet screenshot is the extreme case: the PNG was 530 KB, the JPG at 85% was 737 KB, 39% bigger, and even Compress Image at 70% made it 7% bigger (566 KB). The Python documentation page, the chart page and the desktop dark dashboard also came out bigger as JPG, by 7 or 8%. WebP did not have this problem: its largest result was 71% of the PNG, on that same spreadsheet.
The same spreadsheet shows what lossless WebP can do with flat colour: 115 KB, 22% of the PNG, with every pixel unchanged. On pages that mix text with gradients, maps or photos, such as the weather map and USA.gov, lossless WebP was only 56 to 65% of the PNG and the lossy WebP was much smaller.
Pages with photos
Once a photo fills part of the screen, lossless formats lose their advantage. The NASA home page, with a large photo across the top, was 3.2 MB as a desktop PNG. The JPG was 440 KB (14%), the WebP 218 KB (7%), while lossless WebP still needed 2.3 MB (72%). This is the one group where JPG and Compress Image save as much as people expect, and where a lossless screenshot is hard to justify unless you need it exact. Fidelity stayed high: the median SSIM was 0.992 for the JPG and 0.994 for the WebP.
Dark mode
Dark screenshots were the worst case for JPG. The median JPG was 89% of the PNG, and on three of the seven (both dashboards and the phone MDN page) it saved 4% or less or grew. Light text on a dark background has strong edges everywhere, and the background itself is often a near-black that PNG compresses to almost nothing. WebP held up at a median 44%, and lossless WebP was a median 43%, smaller than the lossy WebP on four of the seven. The phone code-editor screenshot had the lowest JPG score in the test (SSIM 0.9879, against 0.9977 for its WebP), which matches what we saw when we zoomed in.
What happens to the text
Average scores hide where the damage goes, so we also measured the pixels at strong edges only. In a screenshot those are mostly the edges of letters, and they make up a median 13% of the pixels. On those pixels WebP scored a median 33.0 dB PSNR, JPG at 85% 31.3 dB and Compress Image at 70% 28.6 dB. WebP came first on all 20 screenshots, and Compress Image last on all 20. SSIM computed on edge maps, which measures whether outlines keep their shape, gave the same order: 0.996, 0.988 and 0.976.
We then cropped the regions where the JPG differed most from the PNG and compared all four versions. At the screenshot's own pixel size we could barely tell them apart; the Compress Image version had a faint haze around the blue Wikipedia links. Enlarged three times, the differences were clear. JPG at 70% had visible speckle (ringing) around every letter, in the gaps between spreadsheet digits and around blue link text on white. JPG at 85% had the same pattern, fainter. WebP had almost none of that speckle; its main flaw was that thin coloured strokes, such as red and orange code on a dark background, came out slightly softer and duller. Both JPG and lossy WebP store colour at half resolution in each direction, which is why coloured text suffers more than black text.
Because our screenshots were taken at 2× and 3× pixel density, every letter is two or three pixels wider than on a standard screen, and that hides some of the damage. A screenshot from a standard-density monitor has smaller letters, so the same artefacts sit closer to the text and are easier to notice.
Speed
All three tools use the browser's own encoder in Chrome, so speed was not a problem. Encoding alone, measured in the same browser, took a median 27 ms for a desktop JPG and 547 ms for a desktop WebP (343–660 ms); for the smaller phone screenshots it was 16 ms and 243 ms. From choosing the file to the download button being ready, our automated runs took about 1.0 s for JPG and 1.5 s for WebP, including the page's short pause before it starts. For reference, cwebp took a median 2.8 seconds per lossless WebP on the same machine.
All 20 screenshots
| Screenshot | Group | PNG | JPG 85% | WebP 85% | Lossless WebP | SSIM JPG / WebP |
|---|---|---|---|---|---|---|
| Wikipedia: PNG, desktop | Text | 846 KB | 73% | 44% | 47% | 0.9948 / 0.9986 |
| Wikipedia: PNG, phone | Text | 460 KB | 65% | 34% | 55% | 0.9946 / 0.9970 |
| Python docs: os, desktop | Text | 530 KB | 107% | 58% | 30% | 0.9942 / 0.9990 |
| Our spreadsheet, desktop | Interface | 530 KB | 139% | 71% | 22% | 0.9910 / 0.9986 |
| Our chart page, desktop | Interface | 180 KB | 108% | 48% | 43% | 0.9985 / 0.9993 |
| weather.gov, desktop | Interface | 1,363 KB | 40% | 24% | 59% | 0.9964 / 0.9970 |
| NWS forecast, Washington DC, phone | Interface | 315 KB | 84% | 44% | 59% | 0.9957 / 0.9977 |
| USA.gov, desktop | Interface | 900 KB | 37% | 18% | 65% | 0.9958 / 0.9969 |
| USA.gov, phone | Interface | 331 KB | 71% | 34% | 56% | 0.9948 / 0.9983 |
| NASA home page, desktop | Photos | 3,164 KB | 14% | 7% | 72% | 0.9923 / 0.9918 |
| NASA home page, phone | Photos | 1,656 KB | 19% | 9% | 73% | 0.9906 / 0.9929 |
| Wikipedia: Moon, desktop | Photos | 1,114 KB | 60% | 38% | 46% | 0.9931 / 0.9980 |
| Wikipedia: Moon, phone | Photos | 649 KB | 55% | 32% | 56% | 0.9915 / 0.9960 |
| Wikipedia: JPEG, dark theme, desktop | Dark | 981 KB | 61% | 37% | 48% | 0.9910 / 0.9972 |
| MDN: <img>, dark, desktop | Dark | 729 KB | 49% | 25% | 55% | 0.9951 / 0.9978 |
| MDN: <img>, dark, phone | Dark | 202 KB | 99% | 44% | 54% | 0.9948 / 0.9987 |
| Our code editor, desktop | Dark | 411 KB | 81% | 44% | 27% | 0.9940 / 0.9989 |
| Our code editor, phone | Dark | 410 KB | 89% | 49% | 31% | 0.9879 / 0.9977 |
| Our analytics dashboard, desktop | Dark | 190 KB | 107% | 46% | 43% | 0.9972 / 0.9990 |
| Our analytics dashboard, phone | Dark | 138 KB | 96% | 40% | 40% | 0.9964 / 0.9987 |
Which format to use
- Documentation and tutorials. If your site or tool accepts WebP, use it: in our test it roughly halved text and interface screenshots against the PNG and kept letters cleaner than JPG. If you need the exact pixels, for instance for a design spec or a pixel-level comparison, keep the PNG.
- Bug reports. Keep the PNG unless the tracker has a size limit. Exact colours and crisp one-pixel lines can be the bug, and lossy formats blur exactly those. If it is too big, crop to the part that matters before you change the format.
- Social posts and chat. The platform will usually recompress whatever you upload, so the format you send matters less than starting from a clean copy: upload the PNG or a high-quality WebP rather than a JPG that has already been compressed once.
- A screenshot full of photos. This is where JPG is fine. On our four photo-heavy screenshots the JPG was a median 37% of the PNG and WebP 21%. Compress Image goes further, at the cost of visible haze around any text in the shot.
- Avoid JPG for text, spreadsheets, code and dark mode. On 4 of our 20 screenshots the JPG was bigger than the original PNG, and on dark screenshots it saved a median 11%. If a form only takes JPG, PNG to JPG at 85% keeps text readable, but check the size: it is not always smaller.
For the formats in general, see PNG vs JPG vs WebP and what is WebP. Our 13-format conversion test covers the other converters.
How we tested
On 24 October 2026 we captured the screenshots with Playwright 1.64.1 in Chromium 156 on an Apple M2 Mac. Desktop screenshots used a 1440 × 900 viewport at device scale factor 2; phone screenshots used 390 × 844 at device scale factor 3 with a mobile user agent and touch enabled. Each page loaded until the network was idle, then waited 2.5 seconds before the screenshot of the visible viewport, saved as Chromium's own PNG. For the dark-mode pages we set the browser to prefer a dark colour scheme; for Wikipedia we also switched the page to its night theme. Our own pages (code editor, spreadsheet, chart and dashboard) were static HTML files written for this test; the code in the editor is Pixohub's own source. No page showed personal data.
Licences: Wikipedia text is CC BY-SA 4.0, MDN content is CC BY-SA 2.5, the Python documentation is under the PSF licence, and NASA, NWS and USA.gov pages are US government works in the public domain. Images shown on those pages carry their own licences.
Each PNG was uploaded to /png-to-jpg, /png-to-webp and /compress-image in Chromium by script, with default settings, and we saved exactly what the download button returned. In Chromium all three use the browser's own canvas encoder: JPG at quality 0.85, WebP at 0.85 and Compress Image as JPG at 0.70. Every WebP was lossy (its image data is a VP8 chunk, not VP8L), and every JPG used 4:2:0 colour subsampling. Encoding time was measured separately in the same browser, as the median of three canvas.toBlob calls, with decoding excluded. The reference files were made with Pillow 13 (optimize=True) and cwebp 1.6.0 -lossless at its default effort.
We decoded every file with Pillow and compared it with the PNG at full resolution. SSIM is on luminance. For text sharpness we computed a Sobel edge map of each image, then (a) SSIM between the edge maps of the PNG and the output, and (b) RGB PSNR restricted to pixels where the PNG's edge strength exceeded 80, widened by one pixel. We also checked that output dimensions matched and cropped the regions with the largest difference for side-by-side inspection at 1× and 3×. Our general method is described in how we test the tools.
Limits: 20 screenshots is a small sample, and the text-heavy group has only three. The pages change daily, so a new capture of the same URL will give different sizes. Chromium's PNG encoder compresses screenshots fairly well; PNGs from other screenshot tools may be larger, which would make every lossy result look better against them. In Safari, Pixohub encodes WebP with a bundled libwebp instead of the browser, so sizes and times there will differ. We tested one quality setting per tool, the default; a lower slider setting changes the trade-off.