WebP vs PNG

The short answer

WebP almost always replaces PNG for new web content. It produces 20–30% smaller files at bit-identical fidelity, supports a full alpha channel, supports animation, and is rendered by every browser still under vendor support. The case for keeping PNG narrows each year and now comes down to two situations: assets distributed outside the browser (downloadable resources, email attachments, OS clipboard pastes) and a small set of legacy tools that still cannot read WebP.

This page covers when each format wins in practice, what to look at before migrating, and the failure modes that catch teams off guard.

What the two formats are designed for

PNG dates from 1996 and was a direct response to GIF's patent situation. Its design priorities were lossless compression, an 8-bit alpha channel, and a royalty-free specification. It succeeded on all three counts and became the universal format for logos, icons, screenshots, and any web content that needed lossless fidelity or transparency.

WebP launched fifteen years later with a different remit: shrink web images materially without sacrificing the qualities that made PNG and JPEG useful. Lossless WebP was designed specifically to compete with PNG on PNG's own terms — a different compression algorithm that produces visually identical output at materially smaller file sizes.

This is the comparison's key framing. WebP is not a fundamentally different kind of format from PNG; it is a more recent attempt at the same goals. Where PNG used DEFLATE compression (the same algorithm as ZIP), WebP uses a purpose-built combination of spatial prediction, colour transforms, and palette indexing. The output is functionally equivalent; the file size is smaller.

When WebP wins decisively

Any web image where bytes matter

If the image is served to a browser and the page has performance budgets, WebP is the right choice. A typical logo file drops from 12 KB as PNG to 8–9 KB as lossless WebP. For a page with 30 such assets, that is a 100 KB saving. Multiply across a site's traffic and the bandwidth and Core Web Vitals impact compound.

The technical detail behind the size win is covered in WebP format overview and the PNG format overview. The performance implications are in Core Web Vitals & Images.

Photographic content with transparency

PNG is the historical fallback for photographic content with transparency — product shots cut out from backgrounds, for example. As lossy formats, JPEG cannot represent transparency at all. The result is large PNG files for content that would normally compress well as lossy.

WebP solves this elegantly: it can encode the RGB content lossily and the alpha channel losslessly within the same file. A product photo with a clean cut-out routinely drops from 800 KB PNG to 80 KB lossy-WebP-with-lossless-alpha — a 10× win without visible quality loss.

Animated content

PNG itself does not support animation. APNG (Animated PNG) does, but support is uneven and many tools do not produce or recognise it. Animated WebP is supported by every browser that supports static WebP and produces dramatically smaller files than animated GIF. See GIF to WebP.

When PNG still wins

Universal compatibility outside the browser

PNG is supported by every operating system, image viewer, email client, document tool, chat application, and embedded device on the planet. WebP support outside the browser is improving — macOS Big Sur and later, Windows 11, recent iOS and Android — but the long tail still includes plenty of corporate Outlook installations, older Linux distributions, and embedded systems.

Use PNG when the image will live outside the browser:

• Downloadable design resources.
• Email attachments and inline email images.
• Documents (Word, PowerPoint, Pages).
• Press kits, brand asset bundles.
• Clipboard content for copy-paste into arbitrary applications.

For browser-only display, this concern is irrelevant.

Legacy tooling environments

A small set of older creative and corporate tools — some image editors, some CAD packages, some scientific imaging software — still do not read WebP. If your workflow involves passing images between tools where one of them is WebP-unaware, sticking with PNG removes friction.

This is a shrinking set. Photoshop has supported WebP natively since 2022. GIMP since 2.10. Affinity Photo, Pixelmator Pro, Sketch, and Figma all support WebP. The remaining laggards are typically older or niche tools.

Open Graph and social previews

Some social platforms transcode preview images server-side, but the safe choice for <meta property="og:image"> is still JPEG or PNG. WebP coverage in social-preview rendering is improving but inconsistent.

Migration considerations

If you are moving an existing PNG library to WebP, a few practical points:

Keep the PNG originals

The <picture> element fallback pattern needs both formats present. Keep PNG copies alongside the WebP versions for fallback delivery and for any non-browser distribution. The PNG files are dead weight from a browser-delivery standpoint but cheap to retain on disk.

Use lossless mode for PNG sources

A PNG is bit-perfect by definition. Encoding it as lossy WebP introduces a quality loss that did not exist before. For logos, icons, and other content that was deliberately stored as PNG, encode as lossless WebP. For content that was PNG only because of transparency (typically product photos), lossy WebP with lossless alpha is usually correct. The framework is in Lossy vs Lossless.

Convert in batch with the right encoder settings

A naive batch conversion at default settings will leave bytes on the table. Use cwebp -lossless -z 9 for production-grade lossless encoding, or the equivalent through Sharp in a Node pipeline. The detailed parameter set is in WebP Compression Settings.

# Recommended baseline for lossless conversion
cwebp -lossless -z 9 input.png -o output.webp

# Recommended baseline for lossy with lossless alpha
cwebp -q 80 -alpha_q 100 -m 6 input.png -o output.webp

Update HTML to use <picture>

Once converted, swap <img src="logo.png"> for the picture element:

<picture>
  <source srcset="/img/logo.webp" type="image/webp" />
  <img src="/img/logo.png" alt="..." width="240" height="80" />
</picture>

The browser uses WebP when supported and falls back to PNG otherwise. No JavaScript required.

Verify image SEO did not regress

After a large migration, check Google Search Console's Image Search section. Google indexes WebP fine but if your file names changed during migration, individual image rankings may shift. See Image SEO Best Practices.

File size in real numbers

Rough relationships, holding image content constant:

For product photos with transparency, the larger win comes from switching the RGB content to lossy:

The 95% number on the hero photo is the dramatic case: switching from lossless PNG to lossy WebP at q=80 is a 20× improvement, with no visible quality loss for typical hero imagery. This is where teams see the most material performance win from a PNG-to-WebP migration.

Quality considerations

Lossless WebP is bit-identical to the source. There is no quality trade-off — only a file size win.

Lossy WebP introduces compression artefacts that are content-dependent:

• For photographic content, artefacts are invisible at q=80+.
• For content with hard edges or text overlays, lossy at any quality introduces visible ringing. Use lossless or near-lossless for this content.
• For images with extreme detail (fine text, single-pixel features), expect some loss even at high quality.

The framework for predicting which content survives lossy compression is in Lossy vs Lossless.

Browser support nuance

WebP is supported by every browser still under vendor support. PNG is supported by everything including browsers that have not been updated in two decades.

In practice, the gap matters only for sites with significant traffic from very old browsers — typically legacy enterprise customers on IE11 or older. For consumer-facing sites in 2026, the support gap is below 3% of traffic and is fully addressed by the <picture> fallback pattern. Detail in WebP Browser Support.

Recommendation

For new public-facing web content, default to WebP. Use lossless mode for content that PNG would have stored losslessly. Use lossy WebP with lossless alpha for content that PNG was carrying only because of transparency. Keep PNG originals for non-browser distribution.

For an existing PNG library, migrate in batch using the <picture> fallback pattern. Audit the LCP image on each template type and prioritise its conversion — that single image often dominates the performance win.

For content that lives outside the browser, PNG remains the right default and shows no sign of being displaced.

Common questions

Does WebP replace PNG entirely?

For browser-delivered content, yes. For images that travel outside the browser — email attachments, downloadable files, OS clipboard content — PNG remains the right default because of universal tool support.

Will my SEO suffer if I move from PNG to WebP?

No. Google indexes WebP images and uses them for image search. Image SEO depends on alt text, file naming, surrounding content, and structured data — none of which are tied to format. The framework is in Image SEO Best Practices.

Should I serve both formats or just WebP?

Serve both. The <picture> element handles fallback for the < 3% of traffic that does not support WebP. Once the fallback is in place, you can ship WebP as the primary format without worrying about edge cases.

Is animated WebP a replacement for animated PNG (APNG)?

For web use, yes. Animated WebP has broader browser support than APNG, smaller files, and better tooling. APNG remains relevant for niche cases where bit-perfect lossless animation is required and WebP's lossless animation is not enough.

Does WebP compress better than PNG for every image?

Almost always, by 20–30% for lossless content. The rare exceptions are extremely small images (a 16×16 favicon, for example) where the WebP container overhead approaches the size of the payload. For any image larger than about 100 pixels on a side, WebP wins.

Can I convert WebP back to PNG without loss?

If the WebP was encoded losslessly, yes — the round-trip is bit-identical. If the WebP was encoded lossily, the conversion preserves the WebP-quality version (with whatever lossy artefacts that introduced) as a PNG file. The PNG will be larger than the WebP and will not contain any quality that was discarded during the original lossy encoding.

Convert your images

• PNG to WebP — convert existing PNG library
• WebP to PNG — convert WebP back to PNG when needed for distribution

Further reading

• WebP format overview — technical detail on the WebP container and codecs
• PNG format overview — PNG's compression pipeline, alpha transparency, and current relevance
• WebP Optimisation — broader performance walkthrough
• WebP Compression Settings — encoder parameter reference
• Lossy vs Lossless — mode selection
• Core Web Vitals & Images — performance impact