What WebP lossless actually saves you over PNG

The short version

WebP lossless is often smaller than PNG for the same pixels. That is the practical reason people use it.

But the word "often" matters. WebP lossless is not a magic replacement for every PNG. It tends to save the most on images with transparency, screenshots, UI captures, and mixed graphic/photo content. It can save little, or occasionally lose, on very small assets, heavily optimized palette PNGs, and simple icons.

If you are optimizing a real website, the right question is not "Is WebP better than PNG?" It is: "Which of my PNGs get meaningfully smaller as WebP lossless, without creating compatibility or workflow problems?"

That is a narrower question, and much easier to answer.

What "lossless" means here

Lossless means the decoded pixels match the source pixels exactly. If a PNG is converted to WebP lossless and decoded again, the image pixels should be identical.

It does not mean the file is the same. Metadata, color profile handling, ancillary PNG chunks, gamma information, timestamps, and tool-specific chunks may be changed, stripped, or represented differently depending on your conversion pipeline.

This distinction matters if you are dealing with archival images, print workflows, scientific imagery, legal evidence, or any situation where the file container carries important non-pixel information. For ordinary web delivery, most teams care primarily about visual pixels, transparency, dimensions, and color consistency.

If you are publishing user-supplied images, metadata is also a privacy issue. We covered that broader topic in how to strip EXIF metadata before sharing photos online, but the same principle applies here: image optimization should be explicit about what it preserves and what it removes.

Why PNG compresses well, and where it stops

PNG is a very good format. It became a web default for good reasons:

• It is lossless.
• It supports alpha transparency.
• It is widely supported.
• It is predictable and simple to work with.
• It is excellent for flat graphics, screenshots, logos, and UI assets.

PNG compression works by filtering image rows and then applying DEFLATE compression. That combination is effective, especially when nearby pixels are similar.

The problem is not that PNG is bad. The problem is that PNG is old. Its compression model has fewer tricks available than newer formats. Once you have optimized a PNG with a good encoder, you may still be leaving bytes on the table because the format itself cannot represent some patterns as efficiently as WebP lossless can.

That is where WebP lossless enters.

What WebP lossless does differently

WebP lossless uses a compression system designed specifically for images rather than a general-purpose compression layer bolted onto filtered rows. Under the hood, it can use techniques such as predictive coding, color transforms, palettes, backward references, and entropy coding to represent repeating or predictable pixel patterns compactly.

You do not need to memorize the implementation details. The useful mental model is this:

PNG compresses rows well. WebP lossless has more ways to describe image structure.

That extra flexibility is why WebP lossless can frequently produce smaller files from the same source image.

Google has historically described WebP lossless images as being around 26% smaller than PNG on average in its own studies. Treat that as a directional benchmark, not a promise. Your images are not an average. Your design system, screenshots, product photos, illustrations, exported assets, and CMS uploads will have their own behavior.

Where WebP lossless usually saves the most

Transparent images

PNG is commonly used because of alpha transparency. WebP lossless also supports alpha, and often compresses it efficiently.

This is useful for:

• Product cutouts
• Stickers and badges
• Interface overlays
• Diagrams with transparent backgrounds
• Logos exported larger than necessary

The savings can be noticeable when the alpha channel contains large predictable regions, soft edges, or repeated shapes. If you have a catalogue full of transparent product images, WebP lossless is worth testing early.

Screenshots and UI captures

Screenshots often contain large flat areas, repeated interface components, text, icons, shadows, and some photographic regions. That mix can be awkward for PNG, especially at large dimensions.

WebP lossless often handles these images well. A full-page UI screenshot that is 900 KB as an optimized PNG might become 500–700 KB as lossless WebP. Sometimes the saving is larger. Sometimes it is smaller. But the category is promising.

If those screenshots appear in documentation, marketing pages, onboarding flows, or case studies, the aggregate effect can be real.

Mixed illustration and image content

Many modern web graphics are neither pure illustrations nor pure photos. Think of a hero image containing product UI, gradients, small icons, text labels, and embedded photos.

PNG may preserve it perfectly but produce a large file. Lossy WebP or AVIF may create artifacts around text and edges if pushed too hard. WebP lossless can be a sensible middle ground when exact edges matter.

For a broader decision tree across image formats, including AVIF and lossy WebP, see Image formats in 2026: when AVIF beats WebP and when it does not.

Where PNG may still be better

Tiny icons and simple assets

For very small files, format overhead matters. A 650-byte PNG icon is not an obvious candidate for conversion. WebP might save 80 bytes, or it might become larger.

At that scale, the operational complexity may outweigh the benefit. If the file is already tiny, not render-blocking, and cached for a long time, you probably have better things to fix.

Carefully optimized palette PNGs

Some PNGs are much smaller than people expect because they use a limited palette. A good indexed-color PNG can be hard to beat for simple graphics.

This is especially true for:

• Small logos
• Pixel art
• Flat icons
• Simple diagrams
• Graphics with few colors

Be careful when comparing WebP against sloppy PNG exports. If the PNG came straight from a design tool with unnecessary metadata and poor compression settings, WebP may look dramatically better. That does not mean WebP beat a well-optimized PNG by the same margin.

A fair test compares WebP lossless against optimized PNG, not whatever file happened to be uploaded.

Images that should be lossy instead

This is the quiet mistake: teams convert PNG to WebP lossless when the image should not have been PNG in the first place.

Photographs are the usual case. A full-color photograph saved as PNG can be enormous. Converting it to WebP lossless may reduce the file, but it will usually still be much larger than a high-quality lossy WebP or AVIF.

If the user cannot perceive the difference, lossless is often the wrong goal. Product photography, editorial images, backgrounds, and portraits usually belong in a lossy format with sane quality settings.

Lossless should be reserved for cases where exact pixels matter: UI screenshots, diagrams, text-heavy graphics, transparency, generated charts, and assets that visibly degrade under lossy compression.

What it saves besides bytes

The obvious saving is transfer size. Smaller image files usually mean less bandwidth, faster downloads, and better behavior on slow connections.

But there are secondary benefits:

• Less data used by visitors on metered plans
• Faster image cache population
• Reduced CDN bandwidth
• Lower storage and backup volume at scale
• Less pressure on performance budgets

These savings are not evenly distributed. A single 2 MB PNG converted to a 900 KB WebP matters more than fifty icons reduced by 100 bytes each.

This is why image optimization should be prioritized by page impact, not by format ideology. If Lighthouse flags image delivery, read it as a clue, not a verdict. Our guide on how to read a Lighthouse report without panicking explains how to separate meaningful performance problems from noisy diagnostics.

The decode-cost trade-off

Smaller files are not the only performance variable. Browsers also need to decode images before painting them.

PNG decoding is mature and usually fast. WebP decoding is also widely supported and efficient, but it can cost more CPU in some cases. On modern devices this is rarely a blocker, but on low-end phones, image-heavy pages, or large above-the-fold assets, it is worth measuring.

The practical rule: if WebP lossless cuts a large PNG by 30–50%, the network saving usually dominates. If it cuts a small PNG by 3%, the trade-off is probably not worth caring about.

Performance work is full of these threshold decisions. Do not optimize every byte with the same intensity.

A simple testing method

Use a representative batch, not one image.

Create a folder with examples from your actual site:

• Logos and icons
• Screenshots
• Product cutouts
• Diagrams
• CMS-uploaded PNGs
• Social preview images
• Large hero graphics

Then compare three things:

1. The original PNG as uploaded
2. An optimized PNG
3. A WebP lossless version

For command-line workflows, teams often use tools such as oxipng, pngcrush, zopflipng, or cwebp -lossless. The exact tool matters less than the discipline of comparing like with like.

Track:

• File size
• Pixel equality after decode
• Visual rendering in target browsers
• Transparency correctness
• Color appearance
• Build time
• CMS or design workflow friction

A simple spreadsheet is enough. Add the original file size, optimized PNG size, WebP lossless size, percentage saved, and page where the image appears.

Then sort by total bytes saved. That sort order will usually tell you what to do.

Delivery: do not break older clients casually

WebP support is now broad across modern browsers. For most public websites, it is safe to use. Still, if you have embedded webviews, email clients, legacy enterprise browsers, native apps, or unusual crawlers in the mix, test before replacing PNG outright.

The conservative pattern is to keep PNG as a fallback and serve WebP where supported:

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

This approach is boring, and boring is good. Users with WebP support get the smaller file. Everyone else gets the PNG.

If your build system fingerprints assets and your CDN caches them properly, this is not difficult to maintain. If your CMS makes alternate formats painful, start with the largest and most repeated images instead of trying to convert the whole media library in one sprint.

Privacy and local processing

Image conversion often happens in build pipelines or server-side media services. That is fine for many teams. But if you are handling sensitive screenshots, customer uploads, or internal documents, be aware of where files are processed.

Browser-side image tooling has become good enough for many simple conversions, previews, and metadata checks. There are limits, but local processing can reduce unnecessary upload of private images. We covered the trade-offs in why processing images in the browser is a privacy win.

For internal assets, the main point is policy clarity. Know whether images leave the device, where transformed versions are stored, and whether metadata is preserved.

A practical rule of thumb

Use WebP lossless when all three are true:

• The source is currently PNG.
• Exact pixels or clean transparency matter.
• WebP lossless saves a meaningful amount after comparing against an optimized PNG.

Keep PNG when:

• The file is tiny.
• The PNG is already palette-optimized and competitive.
• Compatibility constraints are unusual.
• The operational complexity is not worth the bytes saved.

Use lossy WebP or AVIF when:

• The image is photographic.
• Exact pixels do not matter.
• A quality setting can reduce size dramatically without visible damage.

The best image strategy is rarely one format everywhere. It is a small set of rules applied consistently.

<!-- tool-cta:start -->

💡 Try this: Run the same PNG through the Image Converter to produce a WebP lossless version and compare file sizes directly.

<!-- tool-cta:end -->

So, what does WebP lossless actually save?

It saves bytes where PNG has run out of compression tricks. Sometimes that means a modest 10%. Sometimes it means cutting a large transparent image nearly in half. Across a real site, the savings are usually concentrated in a minority of assets.

That is the important part. WebP lossless is not a moral upgrade from PNG. It is a practical option for a specific job: smaller lossless web images with transparency and broad modern browser support.

Use it where the numbers justify it. Leave PNG alone where they do not.