WebP vs JPEG vs PNG: We Measured All Three — Here's Which to Use When

Ask which image format to use and you'll get a slogan: "WebP is about 30% smaller than JPEG." That figure comes from Google's own comparison, and slogans make poor rules — because the right answer depends on what the image is. A photograph, a screenshot full of text, and a logo with a transparent background behave completely differently under compression. So instead of repeating the slogan, we ran the comparison ourselves: three kinds of content, encoded as JPEG, PNG, and WebP with the same tools, and measured both file size and quality (PSNR, where higher means closer to the original). Here is what the numbers actually say.

The three formats in thirty seconds

JPEG (1992) is lossy-only: it throws away detail your eyes are unlikely to miss, which makes it excellent for photographs. It has no transparency, and it was never designed for sharp edges — text and flat colour are where it struggles.

PNG (1996) is lossless-only: every pixel is preserved exactly. That makes it the safe choice for screenshots, diagrams, and anything with transparency — and a heavy one for photographs, where "exact" costs megabytes.

WebP (2010, from Google) is the only one of the three that does both: lossy compression like JPEG, lossless compression like PNG, plus transparency in both modes. The question is whether that flexibility wins in practice. On our tests, it mostly does — with two exceptions worth knowing.

Test 1: Illustration and photo-like images — WebP wins clearly

Our first sample was a detailed 1920×1280 illustration with gradients, texture, and soft edges — the closest stand-in for a photograph in this test set.

At the same quality setting of 85, WebP produced a file 50.6% smaller than JPEG (132 KB vs 268 KB), with JPEG marginally cleaner on the quality metric. The more useful comparison is across settings: WebP at quality 85 is both smaller and higher-quality than JPEG at quality 70 — 132 KB at 41.88 dB against 161 KB at 40.43 dB. Even in lossless mode, WebP beat PNG by 28.6%. One warning this table demonstrates: quality numbers are not comparable across formats. "85" means something different in each encoder, so compare outputs, not settings.

Test 2: Screenshots and text — JPEG is a disaster, WebP lossless is a rout

The second sample was a 1440×900 user-interface image: flat colour blocks, cards, and text-like bars. This is where format choice matters most.

JPEG's result is the disaster: at quality 85 it produced a file 8.5 times larger than the PNG — and still lossy, with the ringing artefacts JPEG leaves around sharp edges. Flat colour and hard edges are simply hostile to JPEG's design. PNG, built for exactly this content, needed just 6.7 KB. And WebP lossless needed 760 bytes — 88.7% smaller than PNG, with every pixel exact. If you publish screenshots, diagrams, or UI captures, this is the single biggest free win in this article.

Test 3: Logos and transparency — JPEG is disqualified

The third sample was an 800×800 logo-style graphic with a transparent background. JPEG cannot store transparency at all: saving it as JPEG forced the image onto a white background — the transparency was destroyed — and the result was still 25,590 bytes, 4.8 times larger than the PNG (5,386 bytes). Any format comparison that includes JPEG for logos is over before it starts.

Between the two formats that keep transparency, WebP lossless won again: 1,632 bytes, 69.7% smaller than PNG, identical pixels, alpha intact. But this test also produced the article's most counter-intuitive result: lossy WebP at quality 90 came out at 8,982 bytes — larger than its own lossless version, and visibly worse (27.26 dB), because sharp flat edges are the hardest content for a lossy encoder. For small flat graphics, skip lossy entirely; lossless is both smaller and exact.

The decision table

What about browser support?

The historical objection to WebP — "Safari doesn't support it" — is out of date. MDN's image format guide lists WebP support in current Chrome, Edge, Firefox, Opera, and Safari (Safari from version 14, on macOS Big Sur and later). For web delivery in 2026, support is a solved problem. The remaining gaps are outside the browser: some older desktop editors, office suites, and email clients still handle WebP poorly, which is why the decision table keeps JPEG for anything that has to open everywhere, and PNG where a tool chain expects it.

Three rules to take away

1. Match the format to the content, not to a slogan. WebP won most of our tests, but the size of its win ranged from 29% (lossless illustration) to 89% (lossless screenshot) — and lossy WebP actively lost on the small flat graphic.
2. Never use JPEG for text, screenshots, or transparency. In our tests it was simultaneously the largest and the lowest-quality option for that content — the worst of both worlds.
3. Keep a lossless master. Formats are delivery decisions you can remake; detail thrown away by a lossy save is gone. (If you want to see what lossy settings do to a real photo at several quality levels, our earlier hands-on test — Image Compression, Tested — measured exactly that.)

Methodology and sources

All measurements are our own, run on 4 November 2026 with Pillow (libjpeg, libwebp, and PNG with optimisation). Samples: a 1920×1280 illustration (lossless master decoded from a JPEG original, so its PNG baseline reflects the decoded pixels), a synthetic 1440×900 UI/text image, and an 800×800 RGBA logo-style graphic. Sizes are exact byte counts; quality is PSNR against the lossless master for lossy encodes. Your mileage will vary with content and encoder — which is rather the point of the article.

• MDN Web Docs, "Image file type and format guide" — format characteristics and browser support (checked 5 November 2026): https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types
• Google's WebP comparison claim ("roughly 30% smaller than JPEG," from Google's WebP documentation) is the vendor figure this article set out to test rather than repeat.