WebP vs AVIF vs PNG in 2026: Which Image Format Should You Actually Ship?

Published on May 15, 2026 by The Kestrel Tools Team • 9 min read

You’re staring at a 4.2 MB hero image your designer just dropped into the shared drive. The site is already 1.8 seconds slower than your performance budget allows. You open the export dialog, see WebP, AVIF, JPEG, and PNG sitting there like a trick question, and pause. Which one are you actually supposed to ship in 2026?

Most guides answering this question were written between 2020 and 2023. That’s a problem, because the entire calculus changed when Safari 16 added AVIF support in late 2022 and AVIF reached effective Baseline status in early 2025. The advice that says “AVIF isn’t safe to ship yet” is wrong now. The advice that says “just use WebP” is incomplete. And the advice that says “PNG is dead” was never quite right.

This post is a vendor-neutral 2026 decision guide. No CDN sales pitch, no “sign up for our service” conclusion — just the actual tradeoffs, real compression numbers, and a flowchart for picking the right format for the image in front of you. If you want to skip the reasoning and just convert one, Kestrel’s Image Resizer does it client-side in your browser.

Which image format should you use in 2026: WebP, AVIF, or PNG?

Short answer: use AVIF for photos and complex images, WebP as a fallback or default for broad reach, and PNG only when you need lossless transparency or a guaranteed pixel-perfect render (icons, logos, screenshots with text). AVIF wins on file size by 20–50% over WebP for the same visual quality. WebP wins on encode speed and tooling maturity. PNG wins on losslessness and universal compatibility, including environments that strip modern formats (email clients, some CMS imports, legacy CI pipelines).

That’s the executive answer. The rest of this post is the reasoning, the numbers, and the edge cases that make this a real decision instead of a coin flip.

The 2026 browser support reality

The single biggest reason image-format advice from 2022 is stale: Safari was the holdout, and Safari has shipped AVIF for over three years now.

  • WebP is supported in every browser shipping a meaningful number of users — Chrome, Edge, Firefox, Safari (since 14, late 2020), and all modern mobile browsers. Effectively 97%+ global support.
  • AVIF is supported in Chrome (since 85, August 2020), Firefox (since 93, October 2021), Safari (since 16.0, September 2022), and Edge (since 121, January 2024). Global support sits around 95% as of 2026 — past the threshold most teams use to ship without a fallback.
  • PNG is supported everywhere, including environments WebP and AVIF never reach (some email clients, older Word/Outlook embeds, certain CMSes that re-encode uploads).

The practical takeaway: in 2026, you do not need a JPEG fallback for AVIF or WebP for general web use. You may still want one for email or for products that integrate with legacy systems.

Real compression numbers (not marketing numbers)

Vendors love to quote “AVIF saves 50% over WebP.” The truth is messier and more interesting. Here’s what actually happens in the wild, based on widely-replicated tests across photo, illustration, and screenshot content:

  • Photos (JPEG-style content): AVIF is typically 25–50% smaller than WebP at the same perceived quality. WebP is typically 25–35% smaller than JPEG. So AVIF can be roughly half the size of a comparable JPEG.
  • Illustrations and flat-color graphics: WebP and AVIF both crush PNG, often by 60–80%. AVIF’s lead over WebP narrows here — sometimes to single-digit percentage differences.
  • Screenshots with text: PNG is usually still the right choice if you need crisp text edges. Lossy formats can introduce subtle text fringing that’s invisible on a phone but obvious on a 4K monitor in a documentation page.
  • Images with transparency: All three support alpha. PNG is lossless, WebP and AVIF can be either lossless or lossy. AVIF’s lossy alpha is dramatically smaller than PNG’s; WebP sits between them.

A concrete example for calibration: a 1920×1080 photo at “high quality” (visually indistinguishable from the original at normal viewing distance) typically lands around:

  • PNG: 2.5–4 MB
  • JPEG (q=85): 350–550 KB
  • WebP (q=80): 220–360 KB
  • AVIF (q=63): 140–240 KB

Your mileage will vary by 20–30% depending on encoder and content. The order of magnitude does not.

When to use each format: a practical decision tree

Forget benchmarks for a moment. Here’s the actual decision flow most projects need.

Use AVIF when:

  • The image is a photo, hero, or background — anything where the visual is mostly continuous tone
  • You can serve a <picture> element with WebP or JPEG fallback for the ~5% of users without AVIF support
  • File size matters more than encode speed (AVIF encoding is 5–10Ă— slower than WebP)
  • You’re shipping at scale and even small per-image savings compound

Use WebP when:

  • You want one format that handles photos, illustrations, and transparency without a fallback
  • Your build pipeline can’t afford slow AVIF encode times (e.g. dynamic image resizing on a request path)
  • You need broad CMS or third-party tooling support — WebP has had five extra years of ecosystem maturation
  • You’re optimizing on a deadline and “good enough” is the goal

Use PNG when:

  • The image needs to be lossless (UI screenshots, icons, logos, diagrams with thin lines)
  • You’re embedding in environments that don’t reliably support modern formats — email, certain enterprise CMSes, legacy documentation toolchains
  • You need pixel-perfect alpha edges (AVIF and WebP can be lossless, but tooling is rarer)
  • The asset is small enough that the format barely matters (under ~30 KB, the savings are noise)

A note on JPEG

JPEG isn’t dead in 2026, but its niche is narrower than ever. The honest case for JPEG today: maximum compatibility with legacy software, very fast encode in serverless image pipelines, and email. For new web content, WebP and AVIF outclass it on every axis except encoder ubiquity.

How to ship multiple formats with <picture>

If you’ve decided to use AVIF and want a fallback for the holdouts, the modern HTML pattern is the <picture> element. The browser picks the first source it can decode:

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img
    src="/img/hero.jpg"
    alt="Descriptive alt text"
    width="1200"
    height="630"
    loading="lazy"
    decoding="async"
  />
</picture>

Three small things worth getting right:

  • Always include width and height on the <img> to prevent layout shift. The browser uses them to reserve space before the image loads.
  • Use loading="lazy" for below-the-fold images. For your above-the-fold hero, omit it (or use eager) and consider fetchpriority="high".
  • The fallback <img> is what shows up in screen readers, RSS readers, and old browsers. Keep it good.

Common mistakes that waste your savings

A few traps we see often when teams switch formats without changing their habits:

  • Re-encoding from a lossy source. Going from a 100 KB JPEG to AVIF gives you AVIF artifacts on top of JPEG artifacts. Always encode modern formats from the lossless original if you have it.
  • Using AVIF for tiny icons. A 32Ă—32 favicon doesn’t need a fancy codec. The format overhead can make it bigger than a PNG. Below ~5 KB, file format barely matters.
  • Quality settings copy-pasted from JPEG advice. AVIF and WebP use different quality scales. “q=85” doesn’t mean the same thing across formats. Test on real content.
  • Forgetting transparency. If your design uses transparent PNGs and you blindly swap to WebP/AVIF lossy, you can get visible halos around the edges. Use lossless mode for assets with sharp transparency boundaries.
  • Converting and not measuring. “We switched to AVIF” without before/after Lighthouse scores is a vanity migration. Measure LCP and total transfer size before claiming a win.

A quick conversion workflow

The fastest path from “I have a PNG” to “I have all three formats ready to ship” looks like this:

  1. Start from the highest-quality source you have (RAW, lossless PNG, or original SVG).
  2. Resize to the actual rendered size at 1× and 2× DPR — never ship a 4000-pixel-wide image into a 600-pixel container.
  3. Encode AVIF first (slowest), then WebP, then a JPEG fallback.
  4. Compare visually at the rendered size, not at 100% zoom. If you can’t see the difference, ship the smaller file.
  5. Wire up the <picture> element and test in at least one Safari version and one Chrome version.

If you want to do steps 2–3 without uploading anything to a third-party server, Kestrel’s Image Resizer processes everything in the browser using the Canvas API — no upload, no account, no “try our pro plan” popup. That matters when the image is a product mockup, an internal screenshot, or anything else you’d rather not hand to a stranger’s server.

The TL;DR for shipping in 2026

  • Default to AVIF for photos, with a WebP or JPEG fallback via <picture>.
  • Default to WebP for everything else that doesn’t need to be lossless. It’s the safe, fast, mature choice.
  • Keep PNG for icons, logos, screenshots with text, and any environment where modern formats aren’t reliably supported.
  • Stop shipping unoptimized JPEGs for hero images. There’s no excuse left in 2026.
  • Measure the result. If your LCP didn’t move, you optimized the wrong image.

Image format choice isn’t glamorous work. But it’s one of the few remaining places where a few hours of careful decisions can shave a real second off your page load — and your users will feel that long after they’ve forgotten which codec you used.