AVIF, JPEG XL, and the Newer Image Formats

Why newer formats compress better

JPEG's design dates from a time when encoding had to run on very limited hardware. It divides the image into fixed 8×8 blocks, transforms each into frequency components, and discards the ones least likely to be noticed. It works remarkably well for its age, and its characteristic failures — blocking in smooth gradients, haloing around sharp edges — come directly from those design constraints.

Modern formats relax the constraints. They use variable block sizes, so a large area of flat sky is described once rather than as hundreds of separate blocks. They predict each block from already-decoded neighbours in many more ways. They apply filters that smooth block boundaries before they become visible. And they are willing to spend far more computation searching for a good encoding, because computers have it to spare.

The result is meaningfully smaller files at comparable appearance, and fewer visible artifacts when pushed hard. They also close capability gaps: both AVIF and JPEG XL support transparency in lossy mode, high bit depths, and wide colour gamuts, none of which JPEG can do at all.

AVIF

AVIF packages still images using the AV1 video codec's compression machinery. It compresses very well, particularly at low bitrates where it degrades far more gracefully than JPEG — an AVIF file at an aggressive setting tends to look soft rather than blocky.

It supports alpha transparency, high dynamic range, wide colour, and animation. Browser support is broad across current major browsers, which makes it a realistic choice for web delivery today.

The significant practical cost is encoding time. Searching AV1's large space of encoding decisions is expensive, and encoding a large image can take orders of magnitude longer than the equivalent JPEG. For a build step that runs once per image this is a non-issue; for encoding on demand in response to a request it needs careful thought and caching.

AVIF is also less strong on very small images and on flat graphics with sharp edges, where its video-derived machinery has less to work with. Lossless AVIF exists but is not usually competitive with dedicated lossless formats.

JPEG XL

JPEG XL was designed as a general-purpose replacement rather than a video codec adapted to stills, and it has some properties the others do not. It supports both lossy and lossless modes well, handles large images efficiently, and encodes considerably faster than AVIF.

Its most distinctive feature is lossless transcoding of existing JPEG files. An ordinary JPEG can be re-encoded as JPEG XL, becoming substantially smaller, and converted back to a byte-identical original later. For an archive of millions of JPEGs this is a genuinely different proposition from any other format, because the migration is reversible.

It also supports progressive decoding in a sophisticated way, letting a partially downloaded file render as a complete lower-detail image rather than a partially painted one.

Browser support has been the obstacle rather than the technology. Adoption has been uneven and subject to reversals, which is precisely why any specific claim about support belongs in a live compatibility table rather than in an article. Check before relying on it.

Why adoption lags the technical case

Browsers are the fastest-moving part of the ecosystem, and browser support is the part people check. Everything else moves slower, and for most practical purposes everything else is what determines whether a format is usable.

Upload forms are the clearest example. A form's accepted-extension list is written once and revisited rarely. Forms that predate WebP are still common; forms that accept AVIF are unusual. A technically superior file that gets rejected is not superior in any way that matters.

Email clients lag further still. Desktop software, document editors, and operating system preview panes lag variably. Content management systems, print workflows, and internal tools at large organisations can lag by a decade.

There is also an inertia effect that has nothing to do with capability: JPEG works, everyone knows it works, and nobody has ever been blamed for choosing it. Replacing something that works carries risk that the bytes saved rarely justify for any individual decision, even when it is clearly correct in aggregate.

Using them safely

For your own website, the picture element solves the problem cleanly. List an AVIF source first, a WebP source second, and a JPEG or PNG fallback last. The browser takes the first format it supports and ignores the rest, so capable clients get the small file and everyone else gets an image.

This costs storage and build time — you are producing several versions of every image — and buys correctness. Most modern frameworks generate the markup and the derivatives automatically from one source file, which is the right way to do it because the generated format list stays current as support changes.

For a file you are sending to a person or uploading somewhere, the calculation is different and simpler: use JPG for photographs and PNG for graphics unless you have specific knowledge that the destination handles something newer. The recipient cannot pick a fallback, and a file they cannot open wastes both your time and theirs.

For archival storage, prefer formats that are openly specified, widely implemented, and stable. JPEG XL's reversible JPEG transcoding is interesting here precisely because it does not require betting on the new format permanently.

Checking support properly

Any statement about which browsers support which format is out of date quickly, and articles that state it as fact age badly. Compatibility tables are maintained continuously and are the right place to look — treat them as the source and treat any article, this one included, as context.

For a destination that is not a browser, the compatibility table will not help. Test it: upload a small file in the format and see what happens. Five minutes of testing beats any amount of reasoning about what a system ought to accept.

Watch for silent failures rather than clear rejections. Some systems accept a file and then fail to display it, or transcode it to something else, or strip it in a way nobody notices until later. Verifying that the image actually appears where it is supposed to is part of the test.

And remember that your analytics describe your audience, not the general population. If a meaningful share of your visitors use older software, a format supported by 95% of browsers globally may still be the wrong choice for you.