CDN Image Formats: AVIF, WebP, and JPEG XL Optimization Guide

Images account for roughly half of all bytes transferred on the modern web. For CDN operators, image optimization represents the single largest opportunity to reduce bandwidth costs, improve page load times, and lower origin server load. Three next-generation image formats — AVIF, WebP, and JPEG XL — each offer substantial compression improvements over legacy JPEG and PNG, but they differ significantly in browser support, encoding performance, feature sets, and optimal use cases. Understanding these trade-offs is essential for designing a CDN caching strategy that serves the right format to the right client.

The Format Landscape

Legacy JPEG (1992) and PNG (1996) remain the universal baseline. Every browser, image viewer, and operating system supports them. But three decades of compression research have produced dramatically more efficient alternatives. The challenge for CDN infrastructure is not choosing a single winner but orchestrating multiple formats through content negotiation while managing the storage and cache implications of maintaining parallel format variants.

AVIF: Maximum Compression

AVIF (AV1 Image File Format) derives its compression from the AV1 video codec, which was designed by the Alliance for Open Media (Google, Mozilla, Apple, Microsoft, Netflix, and others). AV1 spent years being optimized for video compression at scale, and AVIF benefits directly from that investment. At equivalent perceptual quality (measured by SSIM or VMAF), AVIF produces files 50–60% smaller than JPEG and 30–40% smaller than WebP.

The compression advantage comes from advanced intra-prediction modes, larger transform sizes (up to 64×64), and sophisticated loop filtering that reduces blocking artifacts without softening detail. AVIF also supports 10-bit and 12-bit color depth, HDR content with PQ and HLG transfer functions, and both 4:4:4 and 4:2:0 chroma subsampling.

The trade-off is encoding speed. AVIF encoding at quality settings that produce its headline compression ratios takes 10–50 times longer than JPEG encoding. A 4000×3000 photograph that encodes to JPEG in 100ms might take 2–10 seconds to encode as AVIF with the reference libaom encoder. Faster encoders like SVT-AV1 reduce this gap but still cannot match WebP or JPEG encoding speeds. This makes real-time AVIF encoding at CDN edge nodes impractical for most workloads — the CPU cost per image exceeds the bandwidth savings.

# AVIF encoding with different speed/quality trade-offs

# High quality, slow (archival/pre-encode pipeline)
avifenc input.png output.avif --speed 0 --min 20 --max 32

# Balanced (background processing)
avifenc input.png output.avif --speed 6 --min 24 --max 36

# Fast (closer to real-time, lower compression)
avifenc input.png output.avif --speed 10 --min 28 --max 40

# WebP encoding (fast enough for on-the-fly)
cwebp -q 80 -m 4 input.png -o output.webp

WebP: The Pragmatic Choice

WebP offers the best balance of compression, encoding speed, and browser support. At 25–35% file size reduction versus JPEG, it does not match AVIF's compression ratio, but it encodes fast enough for on-the-fly transformation at CDN edge nodes and enjoys near-universal browser support (97%+ as of 2026). WebP also supports transparency (replacing PNG in many use cases), animation (replacing GIF), and both lossy and lossless compression modes.

For CDN image transformation pipelines, WebP's encoding speed makes it suitable for real-time operations: resize, crop, quality adjustment, and format conversion can all happen at the edge with acceptable latency. A CDN edge worker processing a 1080p image can produce a WebP variant in 30–80ms, adding negligible delay to the first request while subsequent requests serve from cache.

WebP's limitations are modest: maximum image dimensions of 16383×16383 pixels (sufficient for most web use cases), no support for progressive/interlaced decoding (the entire file must download before rendering begins), and no CMYK color space support (relevant only for print workflows). For web delivery through CDNs, these limitations rarely matter in practice.

JPEG XL: The Technical Champion

JPEG XL (JXL) is the most technically advanced format but faces the most uncertain adoption path. Its unique killer feature for CDN operators is lossless JPEG recompression: JPEG XL can convert any existing JPEG file to JXL format with zero quality loss while reducing file size by 20–30%. The original JPEG can be perfectly reconstructed from the JXL file, making this a risk-free optimization for existing image libraries.

Beyond recompression, JPEG XL offers progressive decoding (useful images appear from partial downloads), responsive image support (multiple resolutions in a single file), wide gamut and HDR support, and excellent compression across both photographic and synthetic content (screenshots, illustrations, text). It handles the full spectrum of image types that JPEG and PNG together cover, without requiring different formats for different content.

JPEG XL's adoption challenge stems from Google's decision to remove it from Chrome in 2023. Safari added support, and the format continues to see adoption in imaging applications and archival workflows. For CDN delivery, JXL remains valuable for Safari traffic and as a pre-encoded storage format that can be losslessly converted back to JPEG for browsers that do not support it.

Content Negotiation at the Edge

The standard approach for serving multiple image formats is HTTP content negotiation via the Accept header. Browsers include their supported image formats in this header with every image request. The CDN examines the header and selects the best available format, responding with the appropriate Content-Type and a Vary: Accept header to ensure downstream caches differentiate responses by format.

# Browser Accept headers (examples)

# Chrome/Edge (AVIF + WebP support)
Accept: image/avif,image/webp,image/apng,image/*;q=0.8

# Safari (JPEG XL + WebP support)
Accept: image/jxl,image/webp,image/png,image/*;q=0.8

# Firefox (AVIF + WebP support)
Accept: image/avif,image/webp,*/*

# Legacy browser (JPEG/PNG only)
Accept: image/png,image/*;q=0.8,*/*;q=0.5

The CDN must include the relevant portion of the Accept header in its cache key. Using the full Accept header as part of the cache key creates too many cache variants (browsers send slightly different Accept headers). Instead, normalize the Accept header to a format preference token — for example, "avif", "webp", "jxl", or "default" — and use that token as the cache key discriminator.

# Nginx content negotiation configuration
map $http_accept $image_format_suffix {
    default         "";
    "~image/avif"   ".avif";
    "~image/webp"   ".webp";
    "~image/jxl"    ".jxl";
}

map $http_accept $image_format_type {
    default         "image/jpeg";
    "~image/avif"   "image/avif";
    "~image/webp"   "image/webp";
    "~image/jxl"    "image/jxl";
}

# Serve best available format with normalized cache key
location ~* \.(jpg|jpeg|png)$ {
    set $img_path $uri$image_format_suffix;

    # Try format-specific file first, fall back to original
    try_files $img_path $uri =404;

    add_header Content-Type $image_format_type;
    add_header Vary "Accept";
    add_header Cache-Control "public, max-age=31536000, immutable";

    # Cache key includes normalized format preference
    proxy_cache_key "$uri|$image_format_suffix";
}

CDN Image Pipeline Architecture

A production CDN image pipeline handles format conversion as part of a broader transformation chain: resize, crop, quality adjustment, and format selection. The pipeline can operate in two modes: pre-encode (generate all variants at upload time) or on-demand (transform at first request, then cache).

Pre-encoding works best for high-traffic images where the encoding cost is amortized across millions of requests. On-demand transformation suits long-tail content where most images receive few requests and pre-encoding all variants would waste storage. Many CDN deployments use a hybrid approach: pre-encode the most popular images and transform long-tail content on demand.

Cache Efficiency with Multiple Formats

Supporting multiple image formats multiplies cache storage requirements. A single image that previously occupied one cache slot now requires up to four: JPEG (fallback), WebP, AVIF, and potentially JPEG XL. Combined with responsive image sizes (mobile, tablet, desktop, retina), the total variant count per source image can reach 12–20 cached objects.

Cache efficiency strategies for multi-format delivery include tiered caching with format-aware eviction (keep the most-requested format variant, evict least-requested first), origin shield consolidation (one origin request per format variant regardless of edge PoP count), and selective format support (serve only WebP + JPEG on edge PoPs with limited cache capacity, add AVIF only on high-capacity PoPs). For deeper analysis of cache key design with multiple dimensions, see the cache key design guide.

Quality Metrics and

Comparing image quality across formats requires perceptual metrics rather than simple PSNR (which correlates poorly with human perception). SSIM (Structural Similarity Index) provides better correlation but still misses some perceptual artifacts. Butteraugli (developed by Google for JPEG XL quality tuning) and VMAF (developed by Netflix for video quality) provide the best correlation with human perception.

When configuring quality settings across formats for equivalent perceptual quality:

# Approximate equivalent quality settings for perceptual match
# Target: SSIM 0.95 on typical photographic content

JPEG:     quality 80-85  → ~120 KB for 1080p photo
WebP:     quality 75-80  → ~85 KB  (30% smaller)
AVIF:     quality 50-60  → ~55 KB  (55% smaller)
JPEG XL:  quality 75-80  → ~65 KB  (45% smaller)

# Lossless comparison for synthetic content (screenshots, UI)
PNG:      N/A            → ~450 KB for 1080p screenshot
WebP:     lossless       → ~340 KB (25% smaller)
AVIF:     lossless       → ~280 KB (38% smaller)
JPEG XL:  lossless       → ~260 KB (42% smaller)

Quality settings should be tuned per content type. Photographic images tolerate more aggressive compression than text-heavy screenshots or product images with fine detail. CDN image pipelines that classify content type (photograph, illustration, screenshot, product) before selecting quality parameters consistently outperform those using a single quality setting for all content. This classification can be as simple as analyzing color histogram entropy — photographs have smooth histograms while synthetic images have sharp peaks at specific colors.

Responsive Images and Format Selection

The HTML <picture> element enables client-side format selection combined with responsive sizing. The browser evaluates <source> elements in order, selecting the first one it supports. This gives the content author explicit control over format priority without relying on server-side content negotiation.

<picture>
  <source type="image/avif"
          srcset="photo-400.avif 400w,
                  photo-800.avif 800w,
                  photo-1200.avif 1200w"
          sizes="(max-width: 600px) 400px,
                 (max-width: 1000px) 800px,
                 1200px">
  <source type="image/webp"
          srcset="photo-400.webp 400w,
                  photo-800.webp 800w,
                  photo-1200.webp 1200w"
          sizes="(max-width: 600px) 400px,
                 (max-width: 1000px) 800px,
                 1200px">
  <img src="photo-800.jpg"
       srcset="photo-400.jpg 400w,
               photo-800.jpg 800w,
               photo-1200.jpg 1200w"
       sizes="(max-width: 600px) 400px,
              (max-width: 1000px) 800px,
              1200px"
       alt="Product photograph"
       loading="lazy"
       decoding="async"
       width="1200" height="800">
</picture>

The <picture> approach works independently of CDN configuration — no Vary header or content negotiation needed because each format has a distinct URL. This simplifies CDN caching (one URL = one cached object) at the cost of more complex HTML markup. Server-side content negotiation (single URL, Vary header) keeps HTML simple but requires CDN cache key configuration. For most CDN deployments, server-side negotiation provides better cache efficiency because it consolidates requests to a single URL rather than splitting traffic across format-specific URLs. For more on responsive delivery strategies, see the responsive images guide.

Migration Strategy

Migrating an existing image library to next-generation formats follows a phased approach. Start by enabling WebP serving via content negotiation — this covers 97% of browsers with fast encoding and broad tooling support. Measure the bandwidth savings and verify no visual quality regressions. Then add AVIF for browsers that support it, prioritizing high-traffic images where the larger compression savings have the most impact.

JPEG XL lossless recompression deserves special attention as a zero-risk optimization. Existing JPEG files can be losslessly converted to JXL format, reducing storage and bandwidth by 20–30% with mathematically identical pixel output. The original JPEG can be perfectly reconstructed from the JXL file at any time. For CDN operators with large JPEG libraries, this recompression can be applied to origin storage immediately, serving JXL to Safari users and reconstructing JPEG on the fly for other browsers.

Monitoring format adoption requires tracking several metrics: percentage of requests served in each format, bandwidth savings per format versus JPEG baseline, cache hit ratio per format variant, encoding pipeline throughput and latency, and visual quality scores (automated SSIM/Butteraugli checks in the encoding pipeline). These metrics guide decisions about when to expand format support and when to retire older variants. For comprehensive delivery monitoring, see the CDN observability guide.