Should I convert all of my site's images to AVIF?

Converting everything and deleting the JPGs is a risky approach. The right strategy is to produce the AVIF versions while keeping the JPGs as a fallback and letting the browser download whichever it can support. That way visitors whose browsers support AVIF benefit from the speed gain, while those whose browsers do not simply see the JPG without noticing anything. On top of that, if you need to move to a different format in future, your clean source is still in your hands.

Does moving to AVIF really affect my page speed?

On image-heavy pages the effect is tangible, because images usually make up most of the page weight and downloading less data means a shorter load time directly. The effect is especially pronounced on slow mobile connections and on pages with large hero images or long galleries. Against that, if your page is already light or your bottleneck is not images but server response time or script weight, the gain stays limited. Measuring before and after the change is the only reliable method.

Is JPG considered an obsolete format now?

Not obsolete, just inefficient. JPG is still the most widely supported image format in the world and that alone makes it valuable; no modern format comes close to that universality. It also offers a reasonable quality-to-size balance with photographic content. AVIF beats it clearly on efficiency but cannot come anywhere near it on compatibility. So the right question is not which is better, but how you will use the two together.

How much workload does producing AVIF add to my workflow?

There are two kinds of load. First, you have to produce and store a second version of every image; that means storage and file management. Second, AVIF encoding is computationally heavy and converting a large archive takes noticeably longer than JPG. You also have to update your pages' HTML to deliver with a fallback. On a small site this is a one-off piece of work; on a large site with images being added constantly it is not sustainable without setting up automation.

JPG or AVIF for Website Images?

A question framed the wrong way

The question "JPG or AVIF" assumes the two formats can substitute for each other. In a web context that assumption is mistaken.

AVIF beats JPG clearly on efficiency. JPG, meanwhile, stands somewhere on compatibility that AVIF cannot reach. Professional web development practice does not choose between the two — it serves both and lets the browser choose.

Even so, to make that decision deliberately you need to see clearly what each format offers. In this article we make the comparison honestly.

Efficiency: AVIF is well ahead

At the same visual quality, AVIF generally produces noticeably smaller files than JPG. The commonly cited roughly-half figure is an approximation and the real gain varies considerably from image to image.

The size of the gain depends on the content. The difference is very pronounced in images containing flat colour areas, smooth gradients and wide single-tone regions. In photographs containing heavy noise and fine random texture, the gap narrows.

In a web context this difference is not trivial. Images are the largest item of total data downloaded on most pages. Less data means a directly faster page, especially on slow mobile connections.

AVIF also carries things JPG cannot: an alpha channel, 10-12 bit colour depth, wide colour gamut and HDR. You cannot serve an element requiring transparency with JPG — you are forced to move to PNG and pay a heavy price in size. AVIF handles it in a single file.

Compatibility: JPG has no rival

Current mainstream browsers support AVIF. That is an important threshold for your site and the fundamental reason to take AVIF seriously.

But the picture does not end there:

Older devices and operating systems. Phones and computers that have not received updates in a long time cannot display the file.
Older browser versions. Out-of-date browser use is a real phenomenon in corporate environments and in lower-income markets.
Files the user downloads. When a visitor right-clicks an image and saves it, they end up with an AVIF and may not be able to open it in their desktop program.
Systems outside your control. Someone uploading your image to another platform, attaching it to an email or putting it into a document may run into trouble.

None of these problems arise with JPG. It has worked everywhere for more than thirty years and that is not going to change in the near future.

Quality: the conversion gains you nothing

Let us clear up a common misconception. Converting your existing JPGs to AVIF does not improve the image.

The detail JPG discarded during compression is not in the file; AVIF merely packages what remains more efficiently. If the image has block artefacts, banding or blurriness, it will have them in AVIF too.

More importantly, if you choose too low a quality setting, two layers of lossy compression stack on top of each other and the result becomes visibly worse than the source. When you do the conversion, use a sensible quality value; because AVIF is efficient to begin with, you will still have a serious size gain there.

If you have a cleaner source than the JPG — the original photograph, a PNG version, a raw file — producing the AVIF from that always gives a better result.

Workload: let us be realistic

The overlooked cost of moving to AVIF is operational.

You have to produce and store a second version of every image. You have to update your page templates to deliver with a fallback. You have to repeat that process for every newly added image.

On a small, static site this is a one-off piece of work. On a site with content being added continuously it is not sustainable without automation. If your content management system can generate image variants automatically, the job is easy; if it cannot, you need to design a process.

Factor in as well that AVIF encoding is computationally heavy. Converting a large archive takes noticeably longer than saving as JPG.

The professional answer: both

The real solution to this debate is not to choose.

HTML's picture element lets you define more than one source for the same image. The browser reads the list top to bottom and downloads the first one it can support. A browser that supports AVIF gets the AVIF and benefits from the speed; a browser that does not quietly falls back to JPG and the visitor notices nothing.

The beauty of this approach is that it removes the risk entirely. No visitor sees a broken image, and those who can support it are rewarded.

The practical upshot: produce the AVIF, do not delete the JPGs. The originals are now your fallback layer.

Where should you use which?

Concrete recommendations:

Hero images, large banners, galleries: these gain the most from AVIF, because their sizes are large. Serve them with a fallback.
Small icons and simple graphics: because they are already small the gain is modest; the extra workload may not be worth it. If vector (SVG) is suitable it is usually a better answer.
Images the user is expected to download: product catalogues, press kits, downloadable photographs. Serve JPG here; the user being able to open the file matters more than speed.
Elements requiring transparency: AVIF offers a serious size advantage over PNG here, but the fallback needs to be PNG.

In summary

AVIF wins on efficiency, JPG on compatibility. These two facts do not contradict each other; they complement each other. On an image-heavy site, moving to AVIF delivers a real speed gain, but JPG should be repositioned as a fallback rather than eliminated. Remember that the conversion gains you no quality, and that at low settings it costs you quality. And do not underestimate the workload — an optimisation you cannot sustain is more harmful than one you never did.