Updated: July 6, 2026
Converting PNG to WebP saves space when the PNG contains photos, gradients, transparency with complex detail, or other high-color content. It may not save space for tiny icons, simple flat-color logos, already-optimized PNGs, or screenshots that must remain pixel-exact. Google's published benchmark says lossless WebP is about 26% smaller than PNG on average; lossy WebP can be much smaller for photo-like images, but the exact result depends on the image content and quality setting. The safe workflow is straightforward: convert a copy, compare bytes, inspect quality, and keep the smaller file.
Key Takeaways
- Google's benchmark: lossless WebP is about 26% smaller than PNG on average.
- Lossy WebP can be much smaller for photo-like images, but the saving depends on content and settings — there is no universal guarantee.
- WebP can end up larger than PNG for tiny images, flat-color graphics, and already-optimized PNGs.
- Pick the right mode: lossless for screenshots and logos, lossy for photos, near-lossless as a useful middle ground for detailed graphics.
- WebP has about 96% global browser coverage as of 2026 (per Can I Use), including Safari 14 and later — it is safe for most modern projects.
- Always verify: convert, compare byte sizes, inspect quality, and keep the original until you are sure.
Quick Decision: Convert, Test, or Keep PNG
| Image type | Recommended action | Suggested mode |
|---|---|---|
| Photo or richly colored image | Convert | Lossy (-q 75–80) |
| Complex illustration with gradients | Convert | Lossless or near-lossless |
| Transparent product cutout (complex) | Convert | Lossy with alpha, or lossless |
| UI screenshot, design spec | Test both; keep smaller | Lossless only |
| Small icon or logo (few colors) | Keep PNG or use SVG | — |
| Under ~2 KB or under ~64×64 px | Keep PNG or SVG | — |
| Already optimized with pngcrush / oxipng | Test both; keep smaller | Lossless |
When Converting PNG to WebP Actually Saves Space
Conversion pays off clearly in a few situations.
Photographs saved as PNG. Photos are the worst-case input for PNG: millions of colors and fine gradients make DEFLATE inefficient, so PNG files balloon. Lossy WebP compresses these effectively. A photographic PNG from a camera or a screenshot of a rich, colorful scene often produces a much smaller WebP file at -q 80, with little visible difference.
Rich illustrations and marketing graphics. Complex flat-design hero images, product shots with gradients, and infographics with many colors compress better as WebP. Google's documented lossless benchmark shows roughly 26% savings over PNG, and near-lossless can push further depending on the content.
Transparent images with complex detail. WebP supports an alpha channel in both lossy and lossless modes, so a transparent PNG of a product on a cutout background can convert cleanly at a smaller size — which matters for thumbnails and above-the-fold hero images where bytes translate directly into faster Largest Contentful Paint (LCP).
What Google's WebP benchmark actually says
Google's official WebP page documents two benchmarks directly:
- Lossless WebP vs PNG: lossless WebP images are about 26% smaller than PNGs.
- Lossy WebP vs JPEG: lossy WebP images are 25–34% smaller than comparable JPEGs at equivalent visual quality.
There is no Google-published benchmark for "PNG to lossy WebP." When a photographic PNG converts to lossy WebP, the saving can be substantial — because you are gaining both the format's lossy efficiency and eliminating PNG's overhead for photo content — but the exact result varies by image and quality setting. Treat any specific range as a decision example, not a guarantee, and verify your own files.
| Image type | Expected outcome (decision example, not a guarantee) | Suggested mode |
|---|---|---|
| Photo saved as PNG | Large saving likely; test at -q 75–80 | Lossy |
| Complex illustration | Moderate saving; lossless ~26%; near-lossless may do better | Lossless or near-lossless |
| Transparent product cutout | Saving varies by complexity; test both modes | Lossy with alpha, or lossless |
| Detailed UI screenshot | Small to moderate saving; lossless only | Lossless |
When PNG Can Stay Smaller Than WebP
These are the cases where testing matters before you commit to converting.
Tiny images. WebP files are wrapped in a RIFF container with a fixed header and chunk metadata. For a small favicon or icon, that overhead is a meaningful share of the total file size. PNG has minimal overhead and was designed to handle small graphics efficiently, so it often ends up smaller for very small images.
Very few colors or flat graphics. PNG's DEFLATE compression plus optional palette encoding is extremely efficient for images with a handful of flat colors — a two-tone logo, a simple icon. WebP lossless has little room to improve on what DEFLATE already achieves for this content type, so the savings evaporate or reverse.
Pixel-perfect screenshots and reference images. If the image is a bug-report screenshot, a design spec, or a technical reference where every pixel must stay exact, lossy WebP is the wrong choice — you would lose exactly the fidelity you need. Lossless WebP is correct here, but the gain may be small or negligible.
Already-optimized PNGs. If the PNG has already been processed with pngcrush, oxipng, or a similar optimizer, the lossless WebP saving shrinks further. Test both and keep the smaller file.
| Signal | Likely outcome | Better choice |
|---|---|---|
| Under ~2 KB, or very small dimensions | WebP overhead dominates; PNG often smaller | Keep PNG or use SVG |
| 1–4 flat colors (simple logo or icon) | DEFLATE already efficient; WebP about equal or larger | Keep PNG or use SVG |
| Pixel-exact screenshot or technical reference | Lossy destroys fidelity; lossless gain often small | Keep PNG (lossless WebP only if it is smaller) |
| Already optimized with pngcrush / oxipng | Diminishing returns on re-encoding | Test both; keep the smaller |
Lossless vs Lossy WebP: Which Mode Should You Use?
WebP has two distinct encoders. Choosing the wrong mode is the most common reason conversions disappoint.
| Mode | Best for | Expected saving vs PNG | Pixel fidelity |
|---|---|---|---|
Lossless (-lossless) | Screenshots, logos, UI, pixel-exact art | ~26% (Google benchmark) | Pixel-identical (add -exact for transparent RGB) |
Near-lossless (-near_lossless 60) | Detailed graphics where minor rounding is acceptable | Varies; often better than pure lossless | Not pixel-identical |
Lossy (-q 75–80) | Photographs, complex illustrations | Depends on content and settings | Visually close, not exact |
Lossless is the safe, direct replacement for PNG: same pixels, about 26% smaller on average. Use it for screenshots and logos.
Lossy is where dramatic savings are possible for photo-like content, but it changes pixels. Use it for photos and rich images once you have confirmed the quality holds up at 100% zoom.
Near-lossless applies small, often imperceptible preprocessing — rounding near-identical neighboring pixels — before lossless encoding, which can beat pure lossless with no visible difference. It is not pixel-identical, so do not use it for design or testing assets where exact values matter.
One trade-off worth knowing: WebP lossless can decode slightly slower than PNG on some devices because its prediction model is more complex than DEFLATE. For web delivery this is rarely a bottleneck, but it is a reason not to convert tiny spacers or empty placeholder images.
How to Convert and Verify You Actually Saved Space
Converting is easy; verifying the result is what separates a real optimization from a guess.
1. Convert with cwebp
Google's official encoder is cwebp (part of libwebp). Three commands cover most cases:
# Lossless — pixel-identical, ~26% smaller than PNG on average
cwebp -lossless input.png -o output.webp
# Lossy — best savings for photo-like content
cwebp -q 80 input.png -o output.webp
# Near-lossless — often smaller than pure lossless, not pixel-identical
cwebp -near_lossless 60 input.png -o output.webp
# Lossless with transparent RGB preserved exactly (for design/test assets)
cwebp -lossless -exact input.png -o output.webp
A quick flag reference (from the official cwebp documentation):
| Flag | What it does | Typical use |
|---|---|---|
-q 0–100 | Lossy quality (default 75) | Photos (-q 75–80) |
-lossless | Fully lossless encode | Screenshots, logos |
-near_lossless 0–100 | Light preprocessing then lossless (100 = off, 0 = maximum preprocessing) | Detailed graphics |
-z 0–9 | Lossless compression effort (higher = slower, marginally smaller) | Squeeze every byte |
-alpha_q 0–100 | Alpha channel quality (default 100 = lossless alpha) | Transparent cutouts |
-exact | Preserve RGB values of transparent pixels | Design and testing assets |
-resize W H | Resize during encode | Generate thumbnails |
Prefer a GUI or batch workflow? ImageMagick (magick input.png output.webp), Squoosh, and most CMS image pipelines (WordPress, Next.js next/image) expose these same modes. For a no-install workflow, LessMB's image compressor lets you process images locally in the browser and choose WebP output — useful for quick PNG-to-WebP checks before re-encoding an entire image library.
2. Compare byte sizes
Do not assume WebP won. Check the actual file sizes:
ls -l input.png output.webp
As a practical threshold, many teams keep the PNG unless the WebP is meaningfully smaller — enough to justify maintaining another asset in the pipeline. If lossless WebP is only a few bytes smaller, the gain is unlikely to affect real performance.
3. Check the image visually
Open both files side by side. For lossy conversions, zoom to 100% and examine edges, text, and smooth gradients (sky, skin tones) — these are where artifacts appear first. If you cannot tell them apart, the conversion succeeded.
For lossless conversions on transparent images, confirm the alpha channel renders correctly, especially edges and semi-transparent areas.
4. Serve with a fallback if needed
WebP is safe for most modern web traffic. If your analytics show meaningful traffic from older Safari versions, certain mobile WebViews, or enterprise environments, the <picture> element handles fallback cleanly:
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.png" alt="Hero image" width="1200" height="630">
</picture>
Always include explicit width and height attributes to prevent layout shift.
Should You Convert This PNG? A 60-Second Checklist
Run any image through this before you commit:
- Is it a photograph or richly colored graphic? → Convert (lossy or lossless); verify the result.
- Is it a screenshot, logo, or UI element where pixels must stay exact? → Convert lossless only, or keep PNG if the saving is negligible.
- Is it smaller than about 2 KB or very small in dimensions? → Keep PNG or use SVG — WebP overhead likely wins.
- Does it have only a few flat colors? → Keep PNG or SVG unless lossy degradation is acceptable.
- Does it have a transparency layer? → WebP supports alpha; use lossless or
-alpha_q 100; add-exactif RGB values of transparent pixels must be preserved. - Did you compare byte sizes after converting? → If WebP is not meaningfully smaller, keep the original.
- Did you visually inspect a lossy result at 100% zoom? → Approve only if you cannot see artifacts.
- Did you check LCP and Core Web Vitals before and after? → The bytes saved should show up in real performance data.
Do You Still Need a PNG Fallback?
WebP has roughly 96% global browser coverage as of 2026, per Can I Use, including Chrome, Edge, Firefox, Opera, and Safari 14 and later. For most new public-facing projects targeting modern browsers, WebP is safe to use as a primary format without a fallback.
Where a fallback still makes sense: if your analytics show traffic from older Safari versions, certain mobile WebViews, or enterprise browsers with strict update policies, serve WebP via <picture> with a PNG or JPEG fallback as shown above.
One option worth layering in: AVIF now compresses better than WebP in many cases and sits at around 93% support as of 2026 (per Can I Use). For new projects, serving AVIF first with WebP as a fallback and a final PNG/JPEG backup covers virtually all browsers. We compare the two formats in detail — compression ratios, support gaps, and when each wins — in our AVIF vs WebP guide.
Practical Next Steps
- Audit your heaviest images first. Sort your image folder by size. The largest PNGs — usually photos and hero images — deliver the biggest impact when converted to lossy WebP.
- Convert one copy, compare, keep the original. Never delete the PNG until you have verified the WebP is both smaller and visually acceptable at 100% zoom.
- Pick the mode per image, not globally. Lossless for screenshots and logos; lossy for photos; near-lossless for detailed graphics where invisible rounding is acceptable.
- Add
-exactfor design or testing assets that need the RGB values of transparent pixels preserved. - Automate if you publish frequently. Wire conversion into your build pipeline (Next.js, Vite imagetools) or CDN (Cloudflare, Cloudinary) so every upload is optimized automatically. For occasional checks or one-off conversions, LessMB's image compressor handles PNG-to-WebP locally in the browser without any setup.
- Measure the win. Check your Core Web Vitals — LCP in particular — before and after. The bytes you save should appear in real performance data, not just in file size comparisons.
FAQ
Does WebP always produce a smaller file than PNG?
No. Google's published benchmark says lossless WebP is about 26% smaller than PNG on average, but very small images, simple graphics with few flat colors, and pixel-perfect screenshots can come out the same size or larger. The reason is WebP's RIFF container overhead and the fact that PNG's DEFLATE compression is already near-optimal for flat, low-color content. When in doubt, convert and compare the byte counts.
Should I use lossless or lossy WebP for a PNG?
Use lossless (-lossless) for screenshots, UI elements, logos, and any image where every pixel must stay exact — it is a true drop-in for PNG at about 26% smaller. Use lossy (-q 75–80) for photographs and complex illustrations, where small visual trade-offs deliver much smaller files. Near-lossless is a useful middle ground for detailed graphics, though it is not pixel-identical.
Why is my WebP larger than the original PNG?
This usually happens with very small images, simple flat-color graphics, or already well-optimized PNGs. WebP's RIFF container carries fixed overhead that matters on small files, and PNG's DEFLATE compression is already highly efficient for flat color regions. Keep the PNG, or for simple icons consider SVG instead.
Should I convert PNG screenshots to WebP?
For screenshots where pixel fidelity matters, use lossless WebP — never lossy. If the lossless WebP is not meaningfully smaller than the PNG, keep the PNG. Lossy WebP will introduce visible artifacts in text and fine lines, which makes it the wrong choice for screenshots used in documentation, bug reports, or design specs.
What cwebp command converts PNG to WebP?
Three commands cover most cases: lossless cwebp -lossless input.png -o output.webp, lossy cwebp -q 80 input.png -o output.webp, and near-lossless cwebp -near_lossless 60 input.png -o output.webp. If you need the RGB values of fully transparent pixels preserved exactly — important for design and testing assets — add the -exact flag to the lossless command. Always compare the output size against the original before deleting it.
Can WebP keep transparency like PNG?
Yes. WebP supports an alpha channel in both lossy and lossless modes, so transparent logos and cutouts convert cleanly. In lossless mode, the RGB values of fully transparent pixels are only preserved if you add -exact to the cwebp command; without it, the encoder may adjust those values to improve compression. For design and testing assets where exact pixel values matter, always use -lossless -exact.
Do I still need a PNG fallback for WebP in 2026?
For most modern web traffic, WebP is safe to use as a primary format. If your analytics show meaningful traffic from older Safari versions, certain mobile WebViews, or enterprise browsers with strict compatibility policies, use the HTML <picture> element to serve WebP with a PNG or JPEG fallback. For new public-facing projects targeting modern browsers, a fallback is rarely required.
Sources
- Google Developers — An image format for the Web
- Google Developers — WebP Frequently Asked Questions
- Google Developers — cwebp encoder documentation
- Can I Use — WebP image format
- Can I Use — AVIF image format