Automatic JPEG to AVIF Conversion via CDN Headers

Modern Content Delivery Networks (CDNs) streamline web performance by automatically transforming legacy JPEG images into next-generation AVIF files at the network edge. This real-time optimization is driven by HTTP content negotiation, where the CDN inspects the browser's incoming request headers, determines format compatibility, dynamically converts the image if supported, and caches the result for future users. This process drastically reduces payload sizes without requiring developers to rewrite HTML markup or manually generate multiple file variations at the origin server.

1. Detecting Browser Support via the Accept Header

The conversion workflow begins when a web browser requests an image asset. Along with the URL request, modern browsers send an Accept HTTP request header detailing the MIME types they can decode.

For example, a browser with AVIF support sends a header structured like this:

Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

Because image/avif is explicitly declared, the CDN's edge server immediately identifies that the client can render AVIF images natively. If a browser lacks AVIF support, the image/avif token is omitted from the string, signaling to the CDN that it must fall back to WebP or the original JPEG.

2. Edge-Based Evaluation and Decision Logic

When the request reaches the CDN edge node, a lightweight worker or image optimization engine evaluates several criteria before initiating a conversion:

• Format Capability: Does the Accept header include image/avif?
• Resource Type: Is the requested resource an image format suitable for compression (e.g., JPEG or PNG)?
• File Size and Dimensions: Will converting this particular image to AVIF result in a meaningful byte reduction without degrading visual quality?

If the criteria are met, the edge node checks its local cache for an existing AVIF version of the requested asset.

3. On-the-Fly Image Transcoding

If the AVIF version is not already cached (a cache miss), the CDN handles conversion through an integrated image processing pipeline:

1. Origin Fetch: The edge node fetches the original, high-quality JPEG from the origin server (or pulls it from the origin-shield cache).
2. Decoding and Encoding: Edge compute workers decode the source JPEG into raw pixel data and re-encode it using an AVIF encoder (such as libaom or rav1e).
3. Optimization Tuning: The encoder applies preset compression parameters, stripping unnecessary metadata (such as EXIF data) and balancing the target perceptual quality (SSIM/PSNR metrics) against CPU encoding time.

Because AVIF encoding is computationally intensive, top-tier CDNs often perform this transcoding asynchronously or via dedicated hardware-accelerated processing clusters near the edge to prevent latency spikes on the initial request.

4. Cache Partitioning with the Vary Header

To serve both modern and legacy browsers from the same URL without delivering broken images, the CDN must cache multiple variations of the asset. It manages this using the Vary HTTP response header.

When the CDN delivers the transformed AVIF, it responds with:

Content-Type: image/avif
Vary: Accept

The Vary: Accept header instructs downstream caches, proxies, and browser caches that the returned response is contingent on the client's Accept request header. Consequently:

• Requests containing image/avif receive the cached AVIF payload.
• Requests lacking image/avif (such as older browsers or automated scrapers) are routed to a cache key containing the WebP fallback or the original JPEG.

5. Final Delivery

The client receives the optimized AVIF payload under the original JPEG URL. The browser decodes the AVIF file seamlessly, achieving typical file size reductions between 30% and 50% compared to standard JPEGs, while preserving high visual fidelity and lowering bandwidth consumption. Subsequent requests from other AVIF-capable browsers are served directly from the edge cache, bypassing the encoding step entirely.