JPEG XL vs. AVIF: Which Is the Next-Gen Image Format for the Web?

The competition among web image formats has never been this intense. JPEG XL was once widely expected to take off, only to be shelved in Chrome's roadmap; AVIF, thanks to its early browser support, has spread rapidly—yet developers keep complaining about its encoding speed and toolchain maturity. A recent Hacker News discussion titled "JPEG XL vs. AVIF for web use-cases" has pushed this issue back into the spotlight, with commenters arguing from compression efficiency to progressive decoding to ecosystem support, covering nearly every pitfall you'd actually hit when choosing a format.

The Technical Foundations of the Two Formats

AVIF is based on the intra-frame compression of AV1 video coding—essentially "downscaling" a video codec to still images. The upside is fairly aggressive compression: at equivalent subjective quality, it often shrinks file size to roughly 60% of WebP. The cost shows up on the encoding side: the AV1 encoder is highly complex, takes a long time to build, and its CPU usage when batch-processing large images is hard to ignore.

JPEG XL takes a completely different route. It retains the ability to perform lossless transcoding of traditional JPEGs—existing JPEG files can be repackaged without any quality loss, directly reducing size by about 20%. This means existing image libraries can benefit without re-encoding, a migration path AVIF cannot offer. In addition, JPEG XL natively supports progressive decoding and higher bit depths, making it closer by design to the goal of "replacing JPEG."

A point repeatedly raised in the discussion: the two aren't competing on the same dimension. AVIF is more like "cramming video coding into an image container," while JPEG XL is "redesigning the next generation of JPEG."

AV1 intra-frame compression: AV1 is the next-generation video coding standard led by the Alliance for Open Media (AOMedia). Its intra-frame coding refers to a mode that compresses a single picture without relying on preceding or following frames, using only spatial correlation within the current frame. AVIF "borrows" this mode for still images: the encoder treats each image as a video with only one frame, thereby inheriting AV1's mature toolchain of directional prediction, transform coding, and entropy coding. This also explains why AVIF's encoding complexity is tied to the AV1 encoder—it reuses the same massive engineering implementation, and behind the compression gains is a computational cost.

Lossless JPEG transcoding: JPEG XL has a built-in "JPEG recompression" mode that can repackage the DCT coefficients of an existing JPEG using a more efficient entropy coding and prediction model, while guaranteeing that the decoded pixels are exactly identical to the original JPEG. In other words, it doesn't re-quantize the image—it only replaces the outer encoding method—so quality is strictly lossless while size drops by about 20%. This capability lets existing image libraries benefit without re-encoding, and it's one of the most fundamental differences from AVIF.

Responsive images and content negotiation: Modern websites typically use srcset/sizes to provide multiple sizes for the same image, then use <picture> with something like <source type="image/avif"> to let the browser pick a format based on support. This is what's called content negotiation. Understanding this is crucial: the benefits of format choice are often diluted by size slicing, cache hits, and network conditions, so a format's theoretical maximum compression rate doesn't translate directly into real performance gains.

The Real Trade-offs in Web Scenarios

The Reality of Browser Support

AVIF is already quite well supported in mainstream browsers—Chrome, Firefox, and Safari can all decode it natively, which means it faces almost no deployment friction in production. JPEG XL's situation is far more complicated: Firefox and Safari support it, but Chrome once enabled it experimentally before removing it, leading many teams to cross it off their candidate list outright during evaluation.

This support landscape directly determines the inertia of format selection. For the vast majority of public-facing websites, if more than half of your target users use Chrome, choosing JPEG XL means either giving up optimization gains for that share of users or maintaining an additional fallback logic—and once you fall back to JPEG or WebP, JPEG XL's core advantages are largely diluted.

Background on Chrome removing JPEG XL: Chrome once supported JPEG XL around M91 as an experimental flag, and the community at one point believed it was about to be promoted to stable. But at the end of 2022, the Chrome team removed it from the roadmap, citing "insufficient ecosystem interest and a mismatch between maintenance cost and benefit," sparking widespread controversy. This decision wasn't purely a technical conclusion—it involved Google's long-term investment in the AVIF/AV1 ecosystem. AV1 is co-led by Google, while JPEG XL comes from a competing camp. So the talk of "ecosystem politics" in the discussion isn't unfounded.

Progressive decoding: Progressive decoding means the browser can render a blurry but complete outline of the image as soon as it receives part of the data, then refine it layer by layer. It has a big impact on first-screen perception, especially on slow networks, letting users see content earlier. JPEG XL natively supports this by design, while AVIF's progressive capability is weaker, giving JPEG XL long-term potential in the "outline first, clarity later" experience.

Compression Efficiency Isn't the Same as Real Gains

Developers in the comments pointed out that comparing compression rates in isolation can be misleading. On real websites, images are often responsive, and the same image generates multiple sizes. AVIF usually performs well enough at small and medium sizes, while JPEG XL's lossless transcoding advantage mainly shows up in scenarios with large amounts of existing JPEGs, such as content sites and e-commerce image libraries.

In other words, what determines the benefit isn't the format's theoretical limit but the shape of the image assets you have on hand. A brand-new project starting from scratch with AVIF gets direct benefits and a mature toolchain; a site maintaining hundreds of thousands of historical JPEGs actually finds JPEG XL's transcoding path more cost-effective.

Encoding Speed and Workflow

AVIF's encoding time is the most concentrated complaint in the discussion. Some users mentioned that batch-generating AVIF in CI significantly lengthens build times, requiring caching or distributed encoding to mitigate. JPEG XL's encoder is generally considered friendlier in speed, and lossless transcoding in particular is almost something you do "in passing."

This difference gets amplified in the development experience: optimizing AVIF often requires extra engineering investment in the build pipeline, while JPEG XL's low barrier is easier for small teams to accept.

Points of Disagreement on Hacker News

The discussion wasn't one-sided. The AVIF camp emphasizes the irreplaceability of the ecosystem—solid browser support, mature CDN and image service integrations, and long-term investment around AV1 are all things JPEG XL can't catch up with in the short term. One comment bluntly stated that whether a format wins depends on tooling and platform support, not just compression data.

The JPEG XL camp instead points the finger at Chrome's decision, arguing it looks more like the result of ecosystem politics than a technical evaluation. What they value is the smooth migration enabled by lossless transcoding, plus the format's long-term potential for progressive loading and high dynamic range.

A middle-ground consensus: in the short term, AVIF is the safer default choice, while JPEG XL's value still holds in specific scenarios—especially for projects with massive JPEG assets and control over the client environment.

Practical Selection Advice

Bringing the discussion down to the operational level, you can judge by several dimensions. If your site serves open-internet users, images update frequently, and the team wants to gain optimization at the lowest engineering cost, AVIF with a WebP fallback is the most reliable option today.

If you maintain content archives, e-commerce image libraries, or a controllable client environment (such as an internal enterprise app or desktop client), JPEG XL's lossless transcoding can deliver tangible storage and bandwidth savings, and is worth evaluating.

There's also a path mentioned in the discussion: output both formats and use the picture element with the source element's type attribute for content negotiation. This covers different browsers but increases build complexity and storage overhead—suitable for scenarios extremely sensitive to image performance.

The format war has never been just a contest of technical parameters. Browser vendors' roadmaps, CDN support, and a team's existing engineering investment all influence the final answer. For most developers, figuring out what your image assets actually look like is more meaningful than chasing the "strongest format."

One-line Summary

AVIF vs. JPEG XL: browser support, encoding cost, and the shape of your image assets together determine the choice.

Paragraph Summary

This article, centered on the Hacker News discussion "JPEG XL vs. AVIF for web use-cases," lays out the technical foundations and real trade-offs of the two image formats. AVIF is based on AV1 intra-frame compression—aggressive compression but slow encoding; JPEG XL supports lossless transcoding of existing JPEGs, offers a smooth migration path, and natively supports progressive decoding. Browser support becomes the key to selection: AVIF is natively supported in all three major browsers, while JPEG XL faces deployment friction due to the lack of Chrome support. The article stresses that compression efficiency isn't the same as real gains; what actually determines the benefit is the shape of the site's image assets—brand-new projects suit AVIF, while existing JPEG libraries suit JPEG XL. Finally, it offers selection advice: for the open web, AVIF + WebP fallback is the most reliable; for projects with controllable environments or massive existing assets, JPEG XL is worth evaluating.