WebP vs. AVIF vs. JPEG: A Practical Image Format Guide for 2026

In this comparison, JPEG means the baseline sequential DCT mode commonly used on the web. The JPEG family of standards includes other modes, so this table does not describe every capability in the wider family.

Item	JPEG	WebP	AVIF
Introduced	1992	2010	2019
Standards body or developer	JPEG Committee	Google	Alliance for Open Media
Compression	A widely used reference point	Often smaller than JPEG at similar perceived quality	Can be smaller than WebP or JPEG, depending on the image and settings
Transparency	No	Yes	Yes
Animation	No	Yes	Yes
Lossless mode	No	Yes	Yes
Browser support	Extremely broad	Current major browsers	Current major browsers; verify older operating systems and browsers
Encoding speed	Generally fast	Depends on settings	High-compression settings can be computationally expensive
Decoding speed	Depends on the implementation and image	Depends on the implementation and image	Depends on the implementation and image

Global usage statistics cannot be applied directly to your own audience. Browser support keeps changing, and Safari's AVIF support has differed by operating-system and browser-version combination. Check current compatibility references and your site's own measurements for the environments you actually serve.

The AOMedia specification defines AVIF as an image format that stores a defined subset of AV1 bitstream syntax and semantics in a HEIF file. It is not merely a video keyframe extracted into a file: the specification defines structures and constraints for still images and image sequences.

Its main strengths include:

• Compression efficiency: depending on the image and settings, AVIF can be smaller than JPEG or WebP at comparable perceived quality
• Bit depth: profiles can support 10-bit and 12-bit images, including storage of HDR imagery
• Transparency and animation: both can be represented within the format

Its trade-offs include:

• Potentially high encoding cost: the result varies by implementation, settings, and input. Next.js documentation, for example, says AVIF generally takes longer to encode than WebP, which can affect first-time server transformations and static-site build times
• Limited savings on very small images: container and metadata overhead can make a tiny AVIF larger than a JPEG
• Compatibility with older environments: support within the Safari 16 generation differed by operating system, so a simple “Safari 16+” rule is not precise enough

Support for still AVIF and AVIF image sequences also did not necessarily arrive at the same time. If you plan to deliver animation, check whether each target browser can play AVIF image sequences rather than treating generic image/avif support as sufficient.

HTML provides the <picture> element for this job. The browser evaluates the <source> elements in document order, selects the first eligible source set, and then chooses an image candidate from that set. If no <source> is eligible, the nested <img> provides the fallback source.

<picture>
  <source srcset="/hero.avif" type="image/avif" />
  <source srcset="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="..." width="1200" height="630" />
</picture>

Keep three details in mind:

• Reserve the display ratio on <img>, normally with width and height, to reduce layout shift
• Provide an appropriate alt attribute
• Order <source> elements by your preferred source-set priority. “Newest first” is not an HTML rule; the browser uses the first eligible <source>, then selects a candidate from its srcset according to the applicable descriptors and conditions

Next.js Image

The current default output format for the Next.js Image component is WebP only. To enable AVIF too, configure it explicitly:

// next.config.js
images: {
  formats: ["image/avif", "image/webp"],
}

WordPress

WordPress 5.8 added WebP support, and WordPress 6.5 added AVIF uploads and image processing. AVIF processing still requires the host's Imagick or LibGD installation to support AVIF. WordPress core also does not automatically negotiate AVIF versus JPEG for each visitor. Converting existing images and arranging format negotiation through a CDN require separate design.

Cloudflare Images and Cloudinary

Automatic format selection uses service-specific syntax. Cloudinary provides the f_auto transformation, while Cloudflare URL transformations use a form such as /cdn-cgi/image/format=auto/.... There is no universal ?format=auto API. Consult the service's documentation for cache-key and Accept-header behavior as well.

Photographs, traditionally served as JPEG

AVIF → WebP → JPEG is a strong candidate order. Compare the formats at similar visual quality, then include generation, caching, and maintenance costs in the decision. Generating all three is not always the smallest or simplest overall solution.

Images that need transparency

For photographic images with transparency, AVIF → WebP → PNG is worth testing. For logos and UI assets with sharp edges, compare lossless WebP and AVIF with PNG and SVG. A logo that can be represented as geometry is often best served as SVG.

Animation, traditionally served as GIF

First compare replacing the animation with video such as MP4 or WebM. If it must behave as an image, consider animated WebP or an AVIF image sequence after checking target support and measuring the actual file size.

Icons and extremely small raster images

If the icon can be represented as geometry, SVG is often the better fit. When a raster image is required, measure PNG, JPEG, WebP, and AVIF; for tiny files, headers and container data can account for a meaningful share of the total.

Mandatory legacy support, including IE11

An old browser that does not understand <picture> can still treat the nested <img src="..."> as an ordinary image. Choose a fallback the target environment can display: JPEG for photographs, for example, or PNG for transparency and diagrams. IE11 itself is no longer supported, so whether to include it should be an explicit project requirement.

Reducing transferred bytes with AVIF or WebP can help LCP, but LCP also depends on server response time, resource discovery, priority, decoding, and rendering delay. Changing the format alone does not guarantee an improvement, so confirm the result with field data.

loading="lazy" is useful for images outside the initial viewport. The following example is for an offscreen image. Do not lazy-load the LCP candidate or another initially visible image; consider its fetch priority when appropriate.

<picture>
  <source srcset="/img.avif" type="image/avif" />
  <source srcset="/img.webp" type="image/webp" />
  <img
    src="/img.jpg"
    alt="..."
    width="800"
    height="600"
    loading="lazy"
    decoding="async"
  />
</picture>

Do not add lazy loading to an initially visible hero image or LCP candidate. A nominal “hero” image on another viewport or in a hidden slide may be offscreen, however, so base the decision on its real display conditions. Delaying the LCP candidate can make the metric worse.

• AVIF → WebP → JPEG is a strong option for photographs, but compare using your own images and encoder settings
• AVIF can be smaller, while high-compression settings can impose substantial generation cost
• Order <picture> <source> elements by preferred source-set priority, not merely by age
• Reserve layout space with width and height, and lazy-load only offscreen images
• SVG is often appropriate for small icons; choose the number of raster formats by measured benefit and operational cost
• Verify each CDN's own syntax and caching rules for automatic format selection