WebP vs AVIF vs JPEG vs PNG: Which Image Format to Use

For most photos on a website, serve AVIF or WebP with a JPEG fallback, use PNG only when you need pixel-perfect lossless images like screenshots, and use SVG for logos and icons. No single format wins every job, so the real answer is "pick per image, then let the browser choose with a fallback."

What's the difference between AVIF, WebP, JPEG, and PNG?

They're all raster formats. That means they store a grid of pixels. The difference is how they squeeze that grid into fewer bytes and what extras they support.

• JPEG (1992) is lossy only. It throws away detail your eye is unlikely to miss. No transparency, no animation. It opens everywhere.
• PNG is lossless. Every pixel comes back exactly. It supports full alpha transparency. Files get big with photos.
• WebP comes from Google. It does lossy and lossless, plus transparency and animation, in one format.
• AVIF is based on the AV1 video codec. It also does lossy, lossless, transparency, and animation. It usually compresses photos harder than WebP.
• SVG is different. It's vector, meaning shapes and paths described in XML. It scales to any size with no blur.

"Lossy" means some image data is thrown away for good. "Lossless" means the file is smaller but decodes to the exact original pixels.

Which image format is smallest?

For photos, AVIF usually is, then WebP, then JPEG. PNG is the largest by far for photographic content. But the exact gap depends on the image and the encoder settings, so treat any single number as a rough guide.

Here's what the primary sources claim:

• Google's WebP docs say lossy WebP files are 25–34% smaller than comparable JPEGs at the same SSIM quality index. SSIM is a common way to score how similar two images look.
• The same docs say lossless WebP files are 26% smaller than PNGs.
• MDN says lossy AVIF images are around 50% smaller than JPEGs, and cites a median of 50% savings for AVIF versus 30% for WebP on the same JPEG set.

Those are averages from specific test sets. Your hero photo might save more. A flat-color graphic might save much less, or even come out bigger. Always compare the real output files, and judge them by eye. Our guide to choosing image compression quality settings covers how to test that without guessing.

Is AVIF supported in all browsers?

Yes, in current versions. AVIF became Baseline "newly available" in January 2024, when Edge 121 added support. Baseline is web.dev's label for features that work in all the core browsers on desktop and mobile. MDN lists Chrome 85, Firefox 93, Safari 16.1, and Edge 121 as the first versions with support. Firefox added animated AVIF later, in version 113.

That history is short, though. Older iPhones stuck on pre-16.1 Safari and old Edge builds can't show AVIF. MDN still recommends a fallback, and that's good advice. The <picture> element makes it cheap, as you'll see below.

WebP support is older and broader. The one catch MDN flags is older Macs: desktop Safari needs Safari 14 and macOS Big Sur or later.

What about JPEG XL?

JPEG XL is promising, but you can't rely on it yet. As of this writing, MDN lists it as supported in Safari 17 and later, available in Chrome 145+ only behind a flag, and in Firefox Nightly only. Chrome's default-on date hasn't been announced. If you want to experiment, add it as an extra <source> with a fallback, and check caniuse before you count on it.

Which formats support transparency and animation?

Everything except JPEG handles transparency. Animation is where GIF used to live, and it's the weakest option now.

*PNG itself is lossless, but tools like pngquant cut the color count first, which is a lossy step.

Lossy WebP with transparency is a nice trick. Google says it's typically about 3x smaller than the same image as a PNG. That makes it great for product cutouts on a white or colored page.

A quick note on GIF: for anything longer than a tiny loop, a muted, looping MP4 or WebM <video> is usually far smaller than an animated GIF. Animated WebP and AVIF work too, but video tends to compress motion best.

How slow is AVIF to encode?

Noticeably slower than WebP or JPEG, especially at the slower, higher-effort settings. On a laptop you'll feel it when batch-converting a big photo library. On a server that converts images on upload, it can add real CPU time per image.

A few ways to live with that:

• Encode once at build or upload time, not on every request.
• Use a faster speed setting. The libavif avifenc tool runs from 0 (slowest) to 10 (fastest), with 6 as the default.
• Let an image CDN do the conversion and cache the result.

Decoding is fine for normal page images. The bigger practical difference is that AVIF doesn't render progressively the way a progressive JPEG does. The image tends to appear all at once when it's done, not as a blurry preview that sharpens.

How do you serve AVIF and WebP with a fallback?

Use the <picture> element. The browser walks the <source> list in order and takes the first type it supports. If none match, it loads the <img>.

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Barista pouring latte art"
       width="1600" height="900">
</picture>

1. Put the smallest format first. That's usually AVIF.
2. Always set the type attribute. Without it, the browser can't skip formats it doesn't support.
3. Keep alt, width, and height on the <img>. The sources don't carry them. Width and height stop layout shift, as covered in our post on setting image width and height to prevent CLS.
4. If you also need multiple sizes, add srcset and sizes to each source. Our srcset and sizes guide walks through it.

Some CDNs skip the markup and pick the format from the browser's Accept header instead. That works well, but make sure the CDN sends Vary: Accept or its own equivalent so caches don't hand an AVIF to a browser that can't read it.

When should you still use JPEG?

Whenever you don't control the viewer. That's more often than people think.

• Email. Email client support for WebP and AVIF is patchy, and you can't use <picture> fallbacks reliably in most of them. JPEG and PNG are the safe bet.
• Social share images. Facebook, LinkedIn, Slack, and others fetch your og:image with their own crawlers. JPEG and PNG are the formats that consistently work. See our Open Graph image size guide for the details.
• Downloads. If users save or reuse the file, JPEG opens in every app on every OS.
• The fallback slot. The last <img> in your <picture> should still be a JPEG for photos.

A well-encoded JPEG from mozjpeg is not a bad file. It's just not the smallest one anymore.

When is PNG still the right choice?

Use PNG when every pixel matters and the image isn't a photo. Screenshots of code or dashboards, UI mockups, charts with thin lines, and images with small text all look worse with lossy compression. JPEG smears the edges around text. That's the classic "mosquito noise" you've seen on blurry screenshots.

Lossless WebP can do the same job in a smaller file, so it's a fine <source> with a PNG fallback. And run PNGs through an optimizer like oxipng before you ship them. It's free savings.

Should logos and icons be SVG?

Yes, when the artwork is vector to begin with. A logo in SVG stays sharp on every screen, is often a few kilobytes, and can be styled with CSS. It doesn't need 1x, 2x, and 3x versions. Our post on using SVG images on websites covers safe embedding and when to inline.

Favicons are a special case with their own rules about ICO, PNG, and SVG. Read the favicon formats guide for which files browsers actually request, or turn any image into a full icon set with the favicon converter.

Which image format should you use? A decision table

Common mistakes

• Converting a JPEG to PNG "for quality." The JPEG artifacts are already baked in. You just get a bigger file with the same damage.
• Dropping the type attribute on <source>. Browsers may download a file they can't decode.
• Re-encoding from a lossy file. Convert to AVIF or WebP from the original master, not from an already-compressed JPEG, when you can.
• Serving AVIF as an og:image. Many link-preview crawlers won't show it.
• Assuming AVIF always wins. On flat graphics and small images it can lose to WebP or a tight PNG. Check the bytes.
• Forgetting the size first. A 4000-pixel AVIF shown at 800 pixels is still wasteful. Resize before you pick a format.

TL;DR

Serve photos as AVIF with WebP and JPEG fallbacks through <picture>. Use PNG or lossless WebP for screenshots and text-heavy images, SVG for logos and icons, and plain JPEG or PNG for email and social share images. When in doubt, compare the actual file sizes and look at the results side by side.

Sources

• MDN: Image file type and format guide
• Google for Developers: An image format for the Web (WebP)
• web.dev: Baseline 2024
• MDN: The picture element