Is AVIF really half the size of JPG?

The frequently quoted roughly-half figure is a generalisation and an approximation; it does not hold for every image. The gain depends heavily on content: the difference is very pronounced in images with flat colour areas, smooth transitions and repeating structures. In photographs packed with noise, fine texture and random detail the gap narrows, because that kind of data is hard for any codec to compress. Testing with your own images is the only reliable way to see the actual result.

Why can AVIF compress better than JPG?

The core reason is more than thirty years of engineering difference between them. JPG uses a relatively simple method designed around the processing power of its era, splitting the image into fixed-size blocks. AVIF is based on the intra-frame coding of the AV1 video codec; it can divide the image into variable-sized regions, try a large number of prediction strategies for each region, and pick the cheapest description. That flexibility demands more computation, but it produces a far more compact result in return.

Does this efficiency come at a cost?

Yes, two of them. The first is encoding time: producing an AVIF takes noticeably longer than saving the same image as JPG, because the encoder searches a much wider pool of options. The second, and the more important one, is compatibility; because AVIF is a new format, older devices, older operating systems and many desktop programs cannot open it. Decoding on the viewing side is fast, so there is no problem there.

Does it make sense to convert an already compressed JPG to AVIF?

If you are going to serve it on the web, yes, because you deliver the same image with less bandwidth and your page gets faster. But you need to set your expectations correctly: the detail JPG threw away earlier does not come back, AVIF simply packages what remains more efficiently. Also, if you drop the quality setting too low, AVIF's own degradation piles on top of JPG's existing artefacts and the result gets visibly worse. Working with a sensible quality value removes that risk.

Why Does Switching from JPG to AVIF Shrink the File?

The same image, half the data

You saved a photo as JPG, then saved the same photo as AVIF. The two are indistinguishable on screen, yet the AVIF file is noticeably smaller. How does that happen?

The answer is not magic — it is more than thirty years of accumulated engineering. In this article we explain where AVIF's efficiency comes from, when that efficiency becomes most pronounced, and what you give up in exchange.

What JPG does

Let us first give JPG its due, because it was an extraordinary achievement in its day.

JPG divides the image into small, fixed-size squares. It separates the pixel data in each square into frequency components — roughly speaking, it answers the question "how much smooth transition and how much sharp detail is in this square?" mathematically. It then coarsens or entirely discards the high-frequency components that the human eye struggles to notice.

On top of that, colour information is reduced more aggressively than brightness information, because the eye is far more sensitive to changes in brightness than to changes in colour.

This approach works, and it still works. But it has two fundamental constraints: the blocks are fixed in size and the algorithm's toolkit is fairly narrow. It had to run in a reasonable amount of time on early 1990s computers.

What AV1 changed

AVIF is derived from the intra-frame coding capability of a video codec called AV1. Intra-frame coding is the compression of a single video frame on its own, without looking at neighbouring frames at all. A photograph is also a single frame, so you can apply that capability directly to image compression.

Here are AV1's advantages over JPG:

Variable-sized partitioning. The image does not have to be split into fixed squares. A flat area of sky can be treated as one large region, while a densely detailed face can be broken into much smaller pieces. That means spending only as much data on each area as it actually needs.

A far richer prediction repertoire. The codec tries to predict a region's content from neighbouring regions and records only the difference between the prediction and reality. AV1 has a large number of different prediction directions and methods at its disposal; it finds the one requiring the least data by trying them. JPG has no search of that depth.

More advanced transform and entropy coding. AV1 also uses more modern and more efficient techniques when it comes to expressing the remaining difference numerically.

Smoothing tools. The codec can apply extra processing to soften the block boundaries and banding that compression creates. This makes the image look far less "fallen apart" than JPG at low bitrates.

The overall result is this: at the same visual quality, AVIF is usually noticeably smaller than JPG. The commonly cited roughly-half figure is an approximation; the real gain varies considerably with the content of the image.

What determines the size of the gain?

The efficiency difference is not the same for every image.

Content where the difference is large: Flat colour areas, smooth gradients, wide expanses of sky or wall, repeating patterns, low detail density. AVIF's variable partitioning and prediction mechanism can say a great deal with very little data in this kind of content.

Content where the difference narrows: Heavy noise, fine random texture, film-grain photographs, very high detail density. Random data is hard for any codec to compress; nobody can shorten randomness.

That is why the only correct answer to "how much will I gain by switching to AVIF" is to test with your own images.

AVIF's other capabilities that JPG lacks

Size is not the only dimension of the difference. AVIF also supports several things JPG could never carry:

Alpha channel. It can carry transparent and semi-transparent areas; JPG cannot.
High bit depth. 10 and 12 bits per channel are supported; JPG is limited to 8. This reduces banding in smooth transitions.
Wide colour gamut and HDR. It can carry the broad colour range that modern displays are capable of showing.
Lossless mode. It can be saved without discarding any data if needed, though in that case you give up most of the size advantage.

Let us talk about the price

This efficiency is not free.

Encoding cost. Because the AVIF encoder evaluates far more options, converting an image to AVIF takes noticeably longer than converting it to JPG. For a single file this is trivial; for an archive of thousands of images it is time you need to plan for. Decoding, that is the viewing side, is fast.

Compatibility. This is the real price. Current mainstream browsers support AVIF, but older devices, older operating systems, many desktop programs and a great many upload forms do not. When you email someone an AVIF file, the chance that they cannot open it is real.

That is why, when you move from JPG to AVIF, keeping the originals and holding a JPG fallback for web delivery is standard practice. HTML's picture element was designed for exactly this job: the browser downloads the AVIF if it supports it, and the JPG if it does not.

A warning: an already compressed source

The JPG you have has already been through lossy compression. When you convert it to AVIF you package that image more efficiently, but the lost detail does not come back.

More importantly, if you set the quality too low, two layers of loss stack on top of each other. The AVIF encoder may mistake JPG's leftover block boundaries for "real detail" and try to preserve them, or it may blur everything away. Work with a sensible quality value; because AVIF is efficient to begin with, you will still achieve a serious size gain there.

In summary

AVIF is smaller than JPG not because of smarter compression, but because of more flexible compression that does more computation. When variable region sizes, a broad prediction repertoire and modern entropy coding come together, the same visual quality can be expressed with far less data. In exchange you pay a longer encoding time and — more importantly — limited ecosystem support. For web speed that trade is usually worth it; for file sharing it usually is not.