PNG vs WebP vs AVIF: Which Image Format Should You Use?

Image formats are not just technical trivia — they are one of the most direct levers you have over page speed, Core Web Vitals scores, and ultimately search rankings. Google's Lighthouse audit has flagged “Serve images in next-gen formats” as a high-impact opportunity since 2019, and for good reason: images are typically the single largest payload on any web page, accounting for 60–70% of total page weight on median e-commerce and editorial sites according to the HTTP Archive.

To make the stakes concrete, consider a single full-width hero photograph — the kind that sits at the top of a landing page or blog post. Saved as a well-optimised PNG, that image might weigh 1.2 MB. Converted to WebP at equivalent visual quality, it drops to roughly 380 KB — a 68% reduction. Converted to AVIF, it can land as low as 210 KB — an 83% reduction from the PNG original. On a median mobile connection of 10 Mbps, the PNG takes about 960 ms to download, the WebP takes 304 ms, and the AVIF takes just 168 ms. That difference — nearly 800 ms — is the difference between a page that passes Largest Contentful Paint (LCP) and one that fails.

This guide gives you a genuinely deep technical understanding of how each format works, where each one excels and falls short, and a practical decision framework you can apply to any project today. We'll cover PNG's lossless DEFLATE compression, WebP's VP8 codec heritage, AVIF's AV1 lineage and HDR capabilities, head-to-head benchmarks, browser fallback strategies, and the most common mistakes developers make when migrating between formats.

PNG — Portable Network Graphics — was introduced in 1996 as an open alternative to the patent-encumbered GIF format. Its defining characteristic is lossless compression, meaning the decompressed pixel data is bit-for-bit identical to the original. This is not a minor detail; it is the entire reason PNG exists and the reason it still matters in 2026 despite being three decades old.

How PNG Compression Actually Works

PNG uses a two-stage compression pipeline. In the first stage, each row of pixels is passed through a filter predictor that transforms raw pixel values into residuals — the difference between each pixel and a predicted value derived from its neighbours. PNG defines five filter types (None, Sub, Up, Average, and Paeth), and encoders typically test multiple filters per row and pick the one that produces the smallest residual values. The Paeth filter, for example, uses a clever combination of the left, above, and upper-left pixels to predict each value, and works remarkably well on smooth gradients.

In the second stage, those residuals are fed into DEFLATE — the same algorithm used in ZIP and gzip. DEFLATE combines LZ77 (a sliding-window dictionary compressor that replaces repeated byte sequences with backward references) with Huffman coding (which assigns shorter binary codes to more frequent byte values). The combined effect is that large regions of identical or similar colour — a blue sky, a white background, a flat logo — compress extremely well. A 400×400 white PNG icon might weigh just 1–2 KB.

Where PNG Fails: Photographs

The problem is that photographic images contain millions of subtly different pixel values — film grain, sensor noise, complex textures — that defeat dictionary compression. DEFLATE cannot find the repeated patterns it needs to shrink those files significantly. A 2,000 × 1,333 pixel photograph saved as PNG will typically weigh 2–5 MB even with maximum compression settings, while the same photo as a JPEG at quality 85 might be 350–600 KB. This is not a flaw in PNG; it is the inherent cost of lossless preservation. The format is simply not designed for photographic content.

PNG Is Best For:

• Logos, icons, and brand assets — especially those with flat colours and hard edges
• UI screenshots and technical diagrams where text sharpness is critical
• Source/master files you'll edit repeatedly (no quality loss per save)
• Images with large transparent regions (PNG's 8-bit alpha channel is lossless)
• Pixel art and retro-style graphics where each pixel carries semantic meaning

Google released WebP in September 2010, born out of the On2 Technologies acquisition (which also gave Google the VP8 video codec). WebP's lossy mode is essentially a single intra-coded VP8 video frame — it uses the same block-based DCT transform, motion-less inter-prediction, and adaptive quantisation that made VP8 a competitive video codec. For web images, this means WebP can be 25–35% smaller than JPEG at the same perceptual quality (measured by SSIM or DSSIM), or deliver better quality at the same file size.

Lossy and Lossless Modes

Unlike JPEG (lossy-only) or PNG (lossless-only), WebP supports both modes in a single format container. Lossy WebP is ideal for photographs and complex scenes. Lossless WebP uses a different coding path — WebP Lossless — based on a backwards reference lookup with 2D locality, colour transforms, and an entropy coder called ANS (Asymmetric Numeral Systems). Lossless WebP files are typically 26% smaller than equivalent PNGs for photographic content, though for flat-colour graphics the advantage shrinks considerably since PNG's DEFLATE pipeline is already very efficient on those inputs.

Animated WebP vs GIF

WebP also supports animation, making it a legitimate replacement for GIF. An animated WebP is typically 64% smaller than an equivalent GIF and 19% smaller than an animated PNG (APNG) at comparable quality. This matters because animated GIFs on product pages, marketing emails, and social media embeds are notorious bandwidth hogs — a 5-second looping GIF of a product spin can easily reach 8–15 MB, while the same animation as WebP comes in under 2 MB. The adoption of animated WebP has been slower than static WebP because some email clients and older social platforms still require GIF, but for websites the case is overwhelming.

Browser Adoption Timeline

WebP's browser journey was frustratingly slow for a Google-backed format. Chrome supported it from version 9 (2011), but Firefox didn't add support until version 65 (January 2019) and Safari held out until Safari 14 (September 2020, with iOS 14). By 2022 the format had cleared the 95% browser support threshold, and today it sits comfortably above 97%. For practical purposes in 2026, you can serve WebP as your default format for all photographic content with a JPEG fallback only for IE (which accounts for <0.3% of traffic). The encoding speed is excellent — libwebp can encode a typical photo in milliseconds — making WebP the most practical default for real-time image processing pipelines.

AVIF — AV1 Image File Format — is a child of the AV1 video codec, developed by the Alliance for Open Media (a coalition of Google, Netflix, Apple, Amazon, Microsoft, Mozilla, and others). The spec was finalised in February 2019 and browser support began rolling out that same year. Where WebP took a VP8 intra-frame and wrapped it in a container, AVIF takes a single AV1 intra-coded frame — and AV1's compression tools are far more sophisticated. The result is consistently 20–50% better compression than WebP at equal visual quality, with AVIF files often reaching 50–80% smaller than PNG for the same photographic content.

10-Bit Colour and HDR Support

AVIF's most striking technical advantage over both JPEG and WebP is its support for 10-bit and 12-bit colour depth, compared to JPEG and WebP's 8-bit limit. 8-bit colour gives you 256 levels per channel (16.7 million colours total). 10-bit gives you 1,024 levels per channel — a 4x improvement that eliminates banding in gradients and skies that's often visible in 8-bit images on HDR displays. AVIF also fully supports HDR metadata standards including PQ (Perceptual Quantizer, used by HDR10) and HLG (Hybrid Log-Gamma, used by broadcast HDR), as well as wide-gamut colour spaces like Display P3 and Rec. 2020. This makes AVIF the only widely-supported web image format that can faithfully deliver the full colour capabilities of modern OLED and Mini-LED displays.

The Encoding Speed Tradeoff

AVIF's compression sophistication comes at a cost: encoding is slow. Encoding a single 2,000 × 1,333 image to WebP might take 30–80 ms with libwebp. The same image encoded to AVIF with libaom (the reference encoder) at default settings can take 15–60 seconds — a 200–1,000x increase. Even the faster rav1e encoder takes several seconds. This makes on-the-fly AVIF encoding in a production image server impractical without significant compute resources or caching. The pragmatic solution is to pre-generate AVIF files at build time or during asset upload and serve them from a CDN.

Browser Support Timeline (2019–2026)

Chrome added AVIF support in Chrome 85 (August 2020). Firefox followed in Firefox 93 (October 2021). Samsung Internet added support in version 14 (2021). The most important milestone was Safari 16 on iOS 16 and macOS Ventura (September 2022) — this was the moment AVIF cleared the threshold for practical deployment, since Apple's ecosystem had been the only remaining major holdout. By early 2024, global AVIF support exceeded 93%. In 2026, the only meaningful gap is very old Android WebViews and some legacy smart TV browsers. For virtually all modern web audiences, AVIF is deployable today with a simple WebP or JPEG fallback for the small minority of unsupported browsers.

Raw numbers only tell part of the story, but they matter. The table below distils the key technical differences across eight dimensions. The file size savings column uses a well-optimised PNG as the 100% baseline — all comparisons are at equivalent perceptual quality for photographic content. For non-photographic content (logos, icons) the differences narrow considerably, which is why format choice must always start with content type.

One dimension missing from the table is decode speed — the time it takes for a browser to decompress and paint the image after download. PNG and WebP decode quickly; AVIF decode is somewhat slower due to the more complex bitstream, though hardware decoders are becoming standard in newer chipsets (Apple Silicon, modern Snapdragon) and close this gap significantly. For most web use cases, the download time reduction from AVIF's smaller file size far outweighs any decode overhead on a real network.

Format choice is not purely a technical decision — it depends on your content type, your infrastructure capabilities, your audience's browser profile, and how much engineering time you can invest in a conversion pipeline. Here are six concrete real-world scenarios with specific guidance:

Managing browser support for modern image formats is not as complicated as it might sound, thanks to the HTML <picture> element. The browser reads <source> elements in order and uses the first one it supports — making format negotiation entirely declarative with no JavaScript required. The canonical AVIF → WebP → JPEG cascade pattern looks like this:

<picture>
  <!-- AVIF: ~93% browser support, smallest file size -->
  <source srcSet="/hero.avif" type="image/avif" />
  <!-- WebP: ~97% browser support, excellent compression -->
  <source srcSet="/hero.webp" type="image/webp" />
  <!-- JPEG fallback: 100% support (IE, old Android WebViews) -->
  <img
    src="/hero.jpg"
    alt="Hero image description"
    width="1200"
    height="630"
    loading="lazy"
  />
</picture>

The type attribute on each <source> is the critical piece — it tells the browser the MIME type of the format, allowing it to skip formats it doesn't support without downloading the file first. The fallback <img> tag is what non-picture-aware tools (social scrapers, email clients, CMS image extractors) will use, so always put a JPEG or PNG there.

What Percentage of Users Can't See AVIF?

As of late 2026, approximately 6–7% of global users are on browsers that don't support AVIF. This skews heavily toward: very old Android devices running WebView-based browsers, Internet Explorer users (a tiny but non-zero enterprise population), and some smart TV and game console browsers. Safari has supported AVIF since iOS 16 and macOS Ventura (September 2022), which was the last major platform to add support. For most consumer-facing websites, serving AVIF to 93% of users with a WebP fallback for the remaining 7% is the optimal strategy today.

Format migration projects fail or underdeliver for predictable reasons. Here are the five mistakes we see most often — each of which is entirely avoidable with a little foreknowledge.