JPEG XL vs AVIF

On the technical merits this is genuinely close, and each wins at a different end of the quality range. On browser support it is not close at all.

Head to head

Low bitrate / small files
AVIF. It stays coherent where others fall apart.
High quality / archival
JPEG XL. Better fidelity at the top of the range.
Lossless mode
JPEG XL, comfortably.
Lossless JPEG transcoding
JPEG XL only. Nothing else does this.
Encode speed
JPEG XL, by a wide margin.
Progressive decoding
JPEG XL. AVIF has none.
Browser support
AVIF, decisively. This is what settles it in practice.
Royalty-free
Both.

Comparing them properly

Different design goals

AVIF is a still frame from the AV1 video codec. Video codecs are optimised for delivering acceptable quality at low bitrates across enormous volumes of content, and AVIF inherits that: it is exceptional at making small files that still look coherent.

JPEG XL was designed as an image format from the start, by the committee that produced JPEG. Its priorities are high-fidelity photography, lossless storage, fast encoding and a migration path from the billions of existing JPEGs.

So they are strongest in different places, and comparisons that pick a single bitrate and declare a winner are mostly revealing which end of the range they measured.

Where each one wins

AVIF wins at aggressive compression, where it stays usable at bitrates that visibly break other formats. It also has 10- and 12-bit depth and HDR, and its browser support is broad enough to deploy today.

JPEG XL wins at high quality and lossless, encodes an order of magnitude faster, supports progressive decoding, and can losslessly repack an existing JPEG about 20% smaller with full reversibility — a capability nothing else has.

If you are producing thumbnails and heavily compressed hero images, AVIF. If you are storing a photographic archive or serving high-fidelity images, JXL would be the better format — if you could use it.

The support question, which decides it

AVIF is decoded by Chrome, Firefox, Edge, Opera and Safari. It is deployable today behind a <picture> fallback and needs no argument.

JPEG XL is shipped by Safari. Chrome implemented it behind a flag and then removed it; Firefox keeps its implementation disabled. The situation has shifted more than once and remains contested, so check current support rather than trusting any snapshot — but as things stand, JXL cannot be served to most visitors.

That is not a judgement about which format is better engineered. It is simply what determines which one you can use.

What to actually do

Images on a public website
AVIF, with WebP and JPEG fallbacks. JXL is not an option for most visitors.
On-demand encoding
Neither, realistically — AVIF is too slow and JXL is not supported. Use WebP.
Archival storage you control
JPEG XL, for the lossless JPEG transcode alone.
Professional photography workflow
JPEG XL, if your software supports it.
Apple-only distribution
Either. Safari handles both.

Neither is available here

These tools encode through the browser's canvas, which offers neither format. Chrome and Firefox cannot write AVIF, and no mainstream browser can write JPEG XL.

Worse, a canvas asked for a format it cannot produce silently returns a PNG — so a page offering either would hand most visitors a mislabelled file. The tools here probe what your browser can genuinely encode and disable anything it cannot. For AVIF or JXL output, use avifenc, cjxl, Squoosh or ImageMagick.

Try it yourself

Everything below runs in your browser, so you can test any of this on your own files without uploading them.

  • Compress WebP

    Re-encode existing WebP files, or convert JPEG and PNG into WebP.

    Open the tool
  • JPG to WebP

    Typically 25–35% smaller at matched quality. The standard web win.

    Open the tool
  • Compress JPEG

    Shrink JPG and JPEG photographs with a quality slider or an exact target size.

    Open the tool
  • Bulk compressor

    One setting across a whole folder, processed in parallel, downloaded as a ZIP.

    Open the tool

Questions

Frequently asked questions

Every answer below is present in the page source, expanded, so it can be read without opening anything.

Which is better, JPEG XL or AVIF?

It depends on the bitrate. AVIF is better at aggressive compression and small files; JPEG XL is better at high quality and lossless, encodes far faster, and can losslessly repack existing JPEGs. Browser support currently favours AVIF decisively.

Why is AVIF supported and JPEG XL not?

AVIF arrived alongside the AV1 video codec, which browsers already needed to implement for video. JPEG XL required a separate implementation, and Chrome removed its flagged support citing insufficient ecosystem interest — a decision that drew considerable objection and has been revisited more than once.

Is JPEG XL faster than AVIF?

Substantially, often by an order of magnitude for encoding. That matters enormously for on-demand pipelines and much less for build-time processing that runs once per image.

Can either replace PNG?

Both have lossless modes that beat PNG, with JPEG XL notably stronger. In practice neither replaces PNG today, because PNG works everywhere and these do not.

Should I wait for JPEG XL before optimising my images?

No. WebP already gives you 25–35% off JPEG with universal support, and AVIF adds more if your pipeline can produce it. Waiting for a format that may or may not ship in Chrome costs you real bytes today.

Can I create either format here?

No. Browsers cannot encode AVIF or JPEG XL, and a canvas asked for an unsupported format silently returns a PNG. Rather than hand you a mislabelled file, neither is offered. Use avifenc, cjxl or Squoosh.

From the blog

Related reading

Longer, more practical guides from the blog.

  • Image Formats

    WebP vs JPEG: Which Should You Use, and When JPEG Still Wins

    WebP produced a 27.0 KB file against MozJPEG's 41.1 KB on the same photograph at slightly higher measured fidelity — 34% smaller. It also produced a larger file than JPEG on random noise. The advantage is real and content-dependent.

    9 min read

  • Practical Guides

    How to Compress Images for a Website Without Wrecking Them

    Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.

    8 min read

  • Image Compression

    JPEG Quality Settings Explained: What the Number Actually Means

    Quality 80 is not 80% of anything. It is an index into a quantisation table. Measured on one photograph: dropping from 100 to 90 removes 77% of the file and 4.2 dB of fidelity; dropping from 40 to 30 removes 17% and costs almost as much.

    8 min read