JPEG XL vs. AVIF: The Costs a Compression Chart Misses

Key takeaways

• Compression gains need to be weighed against encoding time, decoding speed, memory use, and maintenance.
• JPEG XL can losslessly recompress existing JPEGs and reconstruct the original files exactly.
• AVIF builds on AV1, but browser image support still requires separate integration work.
• Uneven browser support adds costs for fallback images, storage, and delivery.

Saving bandwidth is the easy part of the pitch for a new image format. For teams weighing JPEG XL against AVIF, the harder question is what those smaller files cost to create, support, and deliver. The compression chart doesn’t show the whole bill.

A browser feature comes with a maintenance bill

For a browser team, supporting an image format means making a long-term commitment.

Connecting a decoder is just the beginning. The browser needs to render colors correctly, handle damaged files, and perform reliably across operating systems and devices.

Then comes the upkeep: decoder updates, security fixes, and tests to catch image-rendering bugs when other browser features change. Once websites depend on a format, removing support becomes harder.

That makes long-term maintenance part of the adoption decision. A new format needs to offer enough additional value to justify that work.

If existing formats already cover most of a service’s needs, the case for another one gets tougher. If the newcomer solves a problem those formats cannot, the argument gets stronger.

These tradeoffs can make caution reasonable. They do not establish why any particular company supports or opposes JPEG XL. They do explain how a browser engineer and an image-service operator could look at the same compression result and reach different conclusions.

“Smaller” needs a few footnotes

Even the file-size comparison needs context.

A photograph and a screenshot full of text present different compression challenges. Results also depend on how much quality loss is acceptable and which encoder settings are used. A useful comparison needs to make those conditions clear.

Then there is encoding time. An image compressed once and distributed for a long time can justify a slower encoding process. A service processing uploads while users wait has a different calculation: more processing time can mean higher server costs and longer delays.

The receiving device has its own work to do. It must decode the file before displaying the image. A smaller download that takes longer to decode or needs more memory deserves a closer look.

The useful question is how a format performs with your images, your quality requirements, and your users’ devices. A winning result under one set of conditions does not settle the production decision.

JPEG XL has JPEG archives. AVIF has AV1.

JPEG XL’s support for lossless JPEG recompression gives it a distinctive appeal: it can recompress an existing JPEG and later reconstruct the original JPEG file exactly.

That preserves the file you already have. It cannot recover image detail discarded when that JPEG was originally created.

For a service with a large JPEG library, this opens up a storage question alongside the usual image-delivery question. Existing files matter as much as newly generated images. The potential savings and processing costs still need to be measured against the actual collection.

AVIF brings a different connection to existing technology. It is based on AV1, which is also used for video compression. Teams that already work with AV1 may be able to draw on their implementation and optimization experience.

But AV1 video playback does not automatically give a browser AVIF image support. The browser still needs to read the image file structure, handle color and transparency, and connect the result to its image-rendering system.

Those advantages will carry different weight in different organizations. A large JPEG archive makes exact file recovery particularly interesting. Existing AV1 expertise may make AVIF more attractive to another team.

Browser support lands on the service’s bill

A format’s technical merits mean little to a visitor whose browser cannot display it.

Websites can offer multiple image candidates through HTML’s picture element. A browser that supports the new format can select it; another can receive a fallback such as JPEG.

That flexibility comes with operational work. Each additional version needs encoding and storage. The CDN has more image variants to handle. Caching and error handling become part of the calculation, too.

Browser compatibility therefore helps determine the cost of adoption. A browser name alone is insufficient: version, operating system, and whether support is enabled by default all matter.

There is also a familiar adoption loop. Services have a stronger reason to invest when enough visitors can use a format. Browser teams have a stronger case for support when websites demonstrate demand. Better compression does not resolve that coordination problem by itself.

A convincing case for adoption starts with measurable gains in the images and infrastructure a service already has. The choice depends on how much that team values smaller files, exact JPEG recovery, and broad browser support. Saved bytes matter; so does who pays to save them.