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

Image format debates often turn into blanket recommendations. In practice, the right format depends on what the image contains, how it is displayed, and which browsers you support.

This guide gives you a decision process, a fallback pattern, and the pitfalls that cause converted images to look worse than the original.

The short version

The table is a starting point. Measure the actual files before committing to a format.

Browser support sets the floor, not the ceiling. WebP has been available since Chrome 32 (2014), Firefox 65 (2019), and Safari 14 (2020). AVIF arrived later: Chrome 85 (2020), Firefox 93 (2021), and Safari 16.1 (2022). A picture element with both formats covers modern browsers without JavaScript, but the fallback still matters for embedded webviews, older corporate browsers, and email clients that render HTML with a limited engine. Check your analytics instead of assuming; a site with 2 percent Safari 15 traffic still has users who will see the JPEG.

The order of decisions is: content type first, transparency second, display size third, browser floor last. Teams often reverse it, pick AVIF because it is newest, and then discover that a 4000-pixel screenshot with text looks worse than the PNG it replaced.

What each format is good at

PNG

PNG is lossless. Every pixel is preserved, which makes it ideal for screenshots, charts, text, and images with sharp edges. The cost is size: photographic PNGs are often several times larger than JPEG or WebP.

Use PNG when:

• You need exact pixel values.
• The image contains text or line art.
• You need broad compatibility.
• You are preparing a source image for further editing.

PNG is also a family of encodings, not a single setting. A screenshot with a few flat colors can be stored as an indexed PNG with a 256-color palette (often called PNG-8), which is commonly a fraction of the size of a 24-bit PNG. Gradients and photos band badly in that mode, so test the actual image rather than converting everything to one preset. PNG supports 8-bit and 16-bit channels, an alpha channel, and animation through APNG; browsers support APNG, but many conversion pipelines silently drop the animation chunks and keep only the first frame. If the output is a still image where an animation used to be, that is the likely cause.

JPEG

JPEG is lossy and widely supported. It is still a reasonable fallback for photographs, but modern formats usually produce smaller files at similar quality. JPEG does not support transparency.

Two JPEG-specific failures are worth knowing. A CMYK JPEG exported from print software can render with inverted or wildly shifted colors in a browser, which expects RGB; the image looks fine in Photoshop and wrong in Chrome. And JPEG stores chroma at reduced resolution (commonly 4:2:0), so sharp red text on a white background develops colored fringes after compression. Progressive JPEG improves perceived loading but does not fix either issue. If the image is a screenshot with colored text, PNG or lossless WebP is the correct source, not a higher JPEG quality setting.

WebP

WebP supports lossy and lossless compression, alpha transparency, and animation. It is supported by all current major browsers and is a safe modern default. Lossy WebP is often 25 to 35 percent smaller than JPEG at comparable quality; lossless WebP is often smaller than PNG for the same pixels.

Use WebP when:

• You want a modern format with broad support.
• You need transparency or animation.
• You want a simpler fallback story than AVIF.

Under the hood, WebP is three related formats: lossy VP8, lossless VP8L, and an extended container (VP8X) for alpha and animation. The encoder decides which one to use; cwebp -q 80 produces lossy WebP, while -lossless produces VP8L, and the two outputs can differ by more than an order of magnitude on the same screenshot. The often-quoted "25 to 35 percent smaller than JPEG" applies to lossy WebP at comparable quality on photographic content, not to every image. On small icons, lossless WebP may be larger than an optimized PNG; on animation, it is usually much smaller than GIF but larger than a well-tuned AVIF.

AVIF

AVIF is based on the AV1 image format. It often produces the smallest files for photographs, especially at low bitrates. It supports transparency and animation, but encoding is slower and support is less universal than WebP.

Use AVIF when:

• You can provide a WebP or JPEG fallback.
• You have a build step that can afford slower encoding.
• You have measured a real size or quality benefit for your images.

AVIF's cost is not only encoding time, which can be several times that of WebP on a large image. Decoding also uses more CPU than JPEG or WebP, which matters on low-end phones and during interaction-heavy pages. The format stores 10-bit color and supports film grain synthesis, so it can look cleaner than WebP at the same file size on gradients and dark scenes, but aggressive quality settings smooth skin and text in ways that are easy to miss on a Retina display. Encode at the size the layout actually uses, compare at 100 percent, and keep the AVIF source out of the repository if the build can regenerate it.

A practical fallback pattern

The picture element lets the browser choose the first supported source:

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

Important details:

• The img is required. It provides the fallback and the alt text.
• width and height reserve space and prevent layout shift.
• loading="lazy" is appropriate below the fold, not for the largest contentful paint image.
• For the LCP image, use fetchpriority="high" and avoid lazy loading.
• The browser downloads only one source in most cases.

The type attribute is what makes the fallback safe. With it, the browser skips a source it cannot decode before downloading. Without it, the browser may select the file, start decoding, fail, and show a broken image instead of trying the next source; the HTML spec does not require a decode failure to fall through. If you add srcset with w descriptors, also add sizes. Without sizes, the browser assumes the image occupies the full viewport width and may download a 1600-pixel file for a 320-pixel card. The symptom is a mobile page that reports a large LCP image even though the layout looks small.

Content negotiation through the Accept header is the server-side alternative: the CDN inspects Accept: image/avif,image/webp,... and returns the best format at the same URL. It produces cleaner markup, but it requires Vary: Accept on the response, or a shared cache will serve an AVIF to a client that cannot decode it. It also makes debugging harder because the URL no longer identifies the format. For static sites, picture is more predictable; for image CDNs that already handle this correctly, negotiation avoids duplicating markup.

Image compression and quality

Format conversion and compression are separate decisions. A WebP file can still be too large if the quality setting is too high or the dimensions are larger than the display size.

A sensible workflow:

1. Resize to the largest size the layout actually displays.
2. Choose a format based on content.
3. Encode at a quality level that looks correct at display size.
4. Compare file sizes and visual quality.
5. Keep the original source image outside the deployed assets.

For screenshots and text, start with lossless WebP or PNG. For photos, start with AVIF or WebP at a moderate quality and compare.

The image compressor can reduce file size without uploading the image to a server. For format changes, use PNG to WebP, JPG to WebP, or AVIF to PNG when you need a compatible source.

Quality numbers are not comparable across codecs. WebP's -q 80 and AVIF's -q 60 both use a 0-100 scale, but the numbers are not calibrated against each other, and the same value in two tools can produce visibly different output. Treat these as starting points, then inspect the result at the display size:

Always convert from the original. Re-encoding a JPEG into WebP does not recover detail; it compounds the first compression and can make the result larger than the JPEG you started with. The same rule applies to resizing: encode once from the full-resolution source at each output width, rather than resizing an already compressed derivative.

Metadata, color profiles, and orientation

Conversion tools may:

• Drop EXIF metadata, including orientation.
• Convert or discard the color profile.
• Change the alpha channel representation.
• Re-encode animation frames differently.

If orientation or color accuracy matters, verify the output. A photo that looks correct in one viewer may appear rotated or desaturated in another if the color profile was removed.

Orientation is a concrete example. Phone cameras often store pixels in landscape and add an EXIF orientation tag such as Rotate 90 CW; browsers honor the tag, so the photo displays upright. A converter that copies the pixels but drops the tag produces a sideways image with no error. exiftool -Orientation photo.jpg shows the original tag, and exiftool converted.webp should either show the same tag or the pixels should already be rotated. Do not assume the library did the right thing.

Color profiles fail more quietly. A photo edited in Display P3 and saved without an ICC profile is interpreted as sRGB, which makes saturated colors look duller; the reverse mistake makes them oversaturated and clipped. In a build pipeline, decide whether to preserve metadata with an option such as sharp().withMetadata() or convert to sRGB explicitly, then verify with exiftool -ColorSpace -ProfileDescription. For public uploads, also strip GPS coordinates with exiftool -gps:all=, because a photo of a product can reveal a home address.

Core Web Vitals

Images affect three metrics:

• LCP: the hero image is often the largest contentful paint. Serve an appropriately sized modern format, avoid lazy loading it, and use fetchpriority="high".
• CLS: set width and height or an aspect ratio so the layout does not jump.
• INP: image decoding can compete with interaction work. Use decoding="async" and avoid enormous images.

The LCP image deserves a preload, but only one. A <link rel="preload" as="image" href="/images/hero.avif" type="image/avif" imagesrcset="..." imagesizes="..."> starts the download before the parser reaches the picture element; preloading every candidate format defeats the purpose and competes with critical CSS. If the image is the LCP element, do not add loading="lazy", and do not hide it behind a CSS background that the preload scanner cannot see. For srcset, a wrong sizes value is worse than no srcset: the browser trusts it, downloads an oversized file, and the LCP metric records the waste.

CLS has a similar trap. width and height attributes reserve space only if CSS does not override them with width: 100%; height: auto on a container that has no aspect ratio. Prefer the modern aspect-ratio property or a wrapper with a fixed ratio so the reserved box survives responsive layout changes. A layout shift of 0.1 is the threshold between "good" and "needs improvement"; a single unsized hero image can exceed it.

A smaller file is not automatically better if it is blurry or if the browser must download multiple sources. Measure the actual page.

When not to convert

Do not convert:

• An image that is already small and well-compressed.
• A PNG screenshot where lossy compression makes text fuzzy.
• An animated GIF with complex timing that the converter cannot preserve.
• An image that must remain byte-identical for legal or archival reasons.

Two more cases are easy to miss. A signed or checksummed asset (for example, an image referenced by a content hash in a manifest) must not be re-encoded after signing; the signature verifies bytes, not pixels. And an image that already passed through an image CDN should not be converted again by the application build, because the CDN will recompress it on delivery and the second lossy pass has no upside. Choose one place in the pipeline to own format conversion.

Conversion is a tool, not a rule. The best format is the one that meets the quality bar at the smallest size for the actual display context.

A decision checklist

1. What is the image content: photo, screenshot, text, icon, or animation?
2. Does it need transparency?
3. What is the largest display size?
4. Which browsers must be supported?
5. Can the build step produce multiple formats?
6. Does the converted file look correct at display size?
7. Are dimensions set to prevent layout shift?

Answer those questions and the format choice becomes obvious. The WebP to PNG converter is useful when you receive a modern format and need a compatible source for editing or upload.

Before shipping, run a short verification pass:

The recommendation can be wrong. If the image is a brand logo or a legal record that must be pixel-exact, PNG or the original file wins regardless of size. If the asset is a tiny icon, SVG or an optimized PNG is usually better than a lossy photo codec. If the delivery target is an email client or a locked-down enterprise browser, JPEG and PNG remain the only formats you can rely on. "Use AVIF" is a default for photographs on the open web, not a universal law.