Modern Image MIME Types: AVIF, WebP, and Fallbacks

Modern Image MIME Types: AVIF, WebP, JPEG, and picture Element Fallbacks

Choosing the right image MIME type affects page weight and browser compatibility. The web image landscape now includes four practical formats, each represented by a distinct MIME type: image/avif for maximum compression with newer browser support, image/webp for good compression with broad support, image/jpeg and image/png as universal fallbacks. Serving the optimal format to each browser requires either the picture element for client-side format selection or CDN-level content negotiation using the Accept header.¹ AVIF achieves smaller files than WebP at equivalent perceived quality, especially at low bitrates where JPEG and WebP produce visible artefacts. WebP reached near-universal browser support ahead of AVIF and remains the safe second choice. Consequently, a progressive delivery strategy serves AVIF to supporting browsers, WebP to those that lack AVIF support, and JPEG or PNG to the remainder. CDN tools like Cloudflare Polish and Imgix handle this format selection automatically.²

AVIF versus WebP compression trade-offs

AVIF uses AV1 intra-frame coding to compress images, the same underlying technology as AV1 video. At low and medium quality levels, AVIF preserves perceptual sharpness better than WebP, which in turn outperforms JPEG at equivalent file sizes. HDR content and wide colour gamut images benefit specifically from AVIF, as it is the only widely-supported web image format with native HDR support.³

Encoding speed versus compression benefit

The practical trade-off is encoding speed: AV1 encoding is computationally intensive. Converting a large image library to AVIF during a build step adds significant processing time compared to WebP conversion. Consequently, many production pipelines delegate AVIF conversion to CDN-level tooling rather than maintaining pre-generated AVIF files in the repository. Building on this, projects using Cloudflare Polish, Imgix, or similar CDN image processors can serve AVIF to supporting browsers without any change to the source image assets or build pipeline.

Browser support and fallback using the picture element

Place source elements inside a picture element in order from most to least compressed. The browser selects the first source element with a type attribute it supports.⁴ Using type="image/avif" on the first source and type="image/webp" on the second, with a JPEG img element as the final fallback, ensures that each browser receives the best format it can handle. The img element's alt attribute and src attribute are required; the picture element itself does not display anything without the img.

srcset for responsive images

The srcset attribute on source elements adds responsive image support on top of format selection, letting you serve different image dimensions to different screen sizes within each format. Combining type and srcset allows serving AVIF at multiple resolutions, falling back to WebP at those same resolutions, with JPEG as the final fallback for browsers that support neither modern format. Browsers evaluate type support first and resolution fit second, always picking the most compressed available format at the appropriate size, which means a 4K display on Chrome receives a large AVIF while the same page on an older Safari gets a smaller JPEG.

CDN-level format negotiation

CDNs that support image format negotiation inspect the Accept request header and serve the best format the requesting browser supports, without any changes to the HTML markup or source image files. Cloudflare Polish, on Pro and Business plans, converts JPEG and PNG images to WebP or AVIF based on the Accept header value and caches the converted versions separately.⁵ Imgix adds f=auto to image URLs to enable automatic format selection including AVIF for supporting browsers. The Next.js Image component uses the Accept header to select between AVIF and WebP automatically when the image optimisation API is enabled. Building on this, CDN-level negotiation is the most operationally simple path to modern image delivery for projects that already use a CDN, since it requires no build tooling changes and handles the MIME type assignment on converted responses automatically.

CSS image-set() for AVIF and WebP in background-image declarations

The picture element only applies to img elements. CSS background images require image-set() to provide format alternatives in background-image declarations. The syntax lists format alternatives with type() hints: background-image: image-set(url("bg.avif") type("image/avif"), url("bg.webp") type("image/webp"), url("bg.jpg") type("image/jpeg")). Browsers evaluate the type() hints against their supported format list and request the winning format.⁶ Chrome, Firefox, and Safari 17.2 support image-set() with type() hints; older Safari requires the -webkit- prefixed form.

The MIME type in each type() hint controls which browsers select which format, mirroring the type attribute behaviour on picture source elements. The server must return the correct Content-Type header for the selected format: image/avif for .avif files and image/webp for .webp files. A mismatch between the type() hint and the actual Content-Type does not prevent display but causes format negotiation to behave inconsistently across browser versions.

Fallback ordering for browsers without image-set() support

Browsers that do not parse image-set() at all skip the property entirely. Placing a plain url() JPEG declaration before the image-set() declaration in the CSS handles this case through the cascade: browsers without image-set() support apply the earlier plain declaration, while browsers that do support it override it with the format-negotiated version. This stacking approach requires no JavaScript or server-side detection.

The same cascade principle applies to the picture element, where ordering the source elements from most to least compressed lets older browsers fall through naturally without any JavaScript. Keeping the plain declaration as the lowest-priority entry guarantees that every browser receives something renderable even when format negotiation fails entirely. map AVIF and WebP Content-Types your server must send for each layer.

When to use this

Use this guide when selecting a modern image delivery strategy for a web project, evaluating the trade-offs between AVIF and WebP, or configuring a CDN to serve format-negotiated images.

Examples