WebP vs PNG vs JPEG: Which Format Should You Serve in 2026?
Last week I ran SnapShrink's batch converter over a folder of 200 demo images for the tool's gallery. One PNG screenshot went in at 412 KB and came out at 96 KB as WebP. Same pixels, no visible difference. That folder is why I stopped treating webp vs png as a taste question. It's arithmetic now. Here's how I decide what to serve.
WebP vs PNG: how much smaller is WebP, really?
WebP is consistently smaller than PNG. Google's published WebP study measured lossless WebP at roughly 26% smaller than equivalent PNG files, and lossy WebP at 25 to 34% smaller than JPEG at comparable visual quality. Savings vary by image, but for anything served on a website, WebP almost always wins on size.
The catch is that WebP has two modes and they behave very differently. Lossy WebP is what you want for photos. Lossless WebP is what you want for screenshots, logos, and anything with text or hard edges. Mixing them up is the most common mistake I see. Lossy on a screenshot smears the text; lossless on a photo wastes bytes for detail your eyes can't see.
One honest caveat from building a converter: for very tiny or simple images, WebP's container overhead can wipe out the compression gain, and I've seen small icons where PNG came out ahead. Spot-check your own assets instead of trusting a rule.
WebP vs PNG for transparency and animation
WebP supports 8-bit alpha transparency and animation, so it covers every job PNG does except one: legacy compatibility. PNG still wins when the destination app only reads PNG, like some email clients, design tools, and old CMS pipelines. For animation, WebP beats GIF on file size, but actual video formats beat both WebP and GIF by a wide margin.
Transparency is the feature that made me stop defaulting to PNG. Early WebP had a reputation for rough alpha edges, but modern encoders handle it fine, and the files are much smaller. The one failure mode I watch for: converting a PNG with semi-transparent pixels and not checking the result. Alpha is the one thing that can break silently, so I always eyeball the converted file against a dark background.
For animation, WebP is technically fine and far smaller than GIF, but the authoring and tooling ecosystem never caught up. Short looping clips belong in muted MP4 or WebM. They compress better than any image format and browsers play them natively.
Where JPEG still beats both
JPEG wins on universal compatibility and encoding speed, not quality per byte. Every device built in the last twenty years reads JPEG, and encoding is instant. For photos served to old email clients, RSS readers, or user-uploaded avatars you don't control, JPEG at 80 to 85 quality remains the safe pick.
JPEG also has no alpha channel and no lossless mode, so don't force it into jobs it can't do. Text screenshots saved as JPEG get that familiar smudged look around every letter, which is why it's the wrong tool for UI images. Use it for photos aimed at destinations you can't control, and use WebP or PNG for everything else.
The 2026 decision framework I actually use
My rule is deliberately boring: photos and screenshots go to WebP, lossy for photos and lossless for anything with text or hard edges, with PNG reserved for tools that force it and JPEG for photos aimed at destinations I can't control. Everything gets wrapped in a picture element so the browser picks the best format it understands.
The picture element does the heavy lifting, so your markup doesn't have to guess:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Product dashboard screenshot" width="1200" height="630" loading="lazy">
</picture>
Browsers read the sources top to bottom and take the first format they support. Old browsers fall through to the JPEG. You can add AVIF at the top of the stack later without touching anything else, which is exactly how I future-proofed the SnapShrink gallery.
| Situation | Serve this | Why |
|---|---|---|
| Photo on a modern site | WebP lossy, ~75-82 quality | Smallest file at good quality |
| Screenshot, logo, UI with text | WebP lossless | Sharp edges, alpha support, far smaller than PNG |
| Destination only accepts PNG | PNG | Compatibility beats bytes |
| Photo for email, RSS, unknown clients | JPEG, 80-85 quality | Universal support, instant encode |
| Short looping animation | Muted MP4/WebM | Beats every image format on size |
| Simple icon | SVG, or PNG if raster | Vector scales; PNG is the safe raster |
How to convert without breaking things
Convert originals to WebP at build or upload time, never by hand-editing files on a live server. Keep your PNG masters archived for anything an external tool might need later, and always check alpha channels after conversion, since a broken alpha channel fails silently and looks terrible on dark backgrounds.
If you want the full file-size numbers and the technical background in one place, I've written a deeper WebP vs PNG comparison on the SnapShrink blog. And for the reverse trip, when some tool insists on a PNG, SnapShrink's free WebP to PNG converter handles the conversion in your browser with no upload.
Two practical gotchas before you convert a whole library. First, social and chat link previews still prefer JPEG or PNG for og:image, so don't WebP your share images. Second, WebP doesn't magically fix a bad source: a blurry JPEG converted to WebP is a small blurry image. Start from the highest-quality original you have.
FAQ
The short version of everything above: serve WebP by default, keep PNG for compatibility, use JPEG for photos aimed at old clients, and try AVIF behind WebP in your picture element if you feel like experimenting. The questions below cover the edge cases I get asked most.
Is WebP always smaller than PNG?
No. For most web images, yes, and usually by a lot. But for very small or very simple images, WebP's container overhead can eat the gain, and PNG sometimes comes out ahead. Test your own assets instead of trusting a blanket rule.
Should I convert my entire PNG library to WebP?
Only the files you actually serve on the web. Keep PNG masters archived. Re-converting from a lossy WebP back to PNG later is a one-way trip you don't want to take.
What about AVIF?
AVIF typically compresses 20 to 30% smaller than WebP's lossy mode, but encoding is noticeably slower and tooling support is still catching up. It's worth trying behind a picture element where WebP is the fallback. Don't rebuild your whole pipeline around it yet.
Does WebP work in every browser?
All modern browsers have supported WebP since around 2020, including Safari from version 14. The picture element pattern above covers the stragglers with a JPEG fallback, so browser support shouldn't stop you.
Remember that 412 KB screenshot from the demo folder? It shipped as a 96 KB WebP and nobody noticed except me, checking the network tab. That's the whole pitch. Pick WebP as your default, keep PNG and JPEG for the jobs they still own, and let the picture element sort out the rest. Your users' bandwidth will thank you.
