Convert JPG to AVIF

JPEG was standardised in 1992 and its compression reflects what was computationally reasonable then: the image is cut into eight-by-eight blocks and each is described independently. AVIF is a still frame of AV1, a video codec from 2018, and it brings thirty years of subsequent research — variable block sizes, prediction from neighbouring regions, far better entropy coding.

In practice that means 40 to 50 per cent smaller at the same visible quality, and the gap widens on exactly the images that dominate most websites: photographs with large smooth areas. A sky, a plain wall, a blurred background — JPEG spends real bits describing each block of them and AVIF predicts almost the whole region from its edges.

AVIF is slow to create. A large photograph takes a few seconds here where a JPG takes a fraction of one, because the encoder is searching a much larger space of ways to represent the image. On a batch of a hundred you will notice.

That cost falls entirely on whoever converts, once. Decoding is fast — visitors are not waiting for anything — and the saved bytes are saved on every request forever. For an image on a page that gets any traffic at all, the arithmetic is not close. For a one-off image in an email, it is not worth the wait, and JPG or WebP is the sensible answer.

WebP is the safer, faster, slightly larger option; AVIF is the smaller, slower one. The gap between them is roughly 20 per cent in AVIF’s favour, which is meaningful on a photograph-heavy page and negligible on a site with a handful of images.

The real answer for anything production is both, inside a `<picture>` element: browsers take the first source they understand, so AVIF is served where it is supported and WebP or JPG elsewhere. That costs a few lines of HTML and removes the need to choose. If you are only going to produce one format, WebP for convenience, AVIF for weight.

Your JPGs are lossy. Detail was discarded when they were made, and converting to AVIF now means encoding what survived — including, in principle, the JPEG artefacts themselves. Generation loss is real and this page will not pretend otherwise.

In practice it is not the problem it sounds like. At sensible quality settings the AVIF is visually indistinguishable from the JPG it came from while being half the size, because the savings come from a better representation rather than from throwing more away. Converting from an untouched original would be better; almost nobody has one, and this remains clearly worth doing.

AVIF numbers do not map onto JPEG numbers. An AVIF around 50 to 60 commonly matches a JPG at 80 to 85, so copying your habitual JPEG figure across usually means producing a file far larger than you needed.

Start lower than instinct suggests and compare. The place to look is not the whole image but the difficult regions: skin, a gradient sky, and any text inside the picture.

Every current browser reads AVIF and has done for several years. Outside the browser it is patchier than WebP: some image viewers, several editors and a number of upload forms still do not know it.

That makes AVIF a format for your own pages rather than for sending to people. If the file is going to a person rather than to a page, JPG remains the answer.

AVIF supports an alpha channel and sequences of frames, so unlike JPG it is not confined to opaque stills. None of that is relevant when the source is a JPG, which has neither.

It matters when you are choosing a target format for a whole site. One format can then cover photographs, logos with transparency and short animations, where JPG needs PNG and GIF standing beside it.

The format can hold EXIF; this conversion writes none. The JPG is decoded to pixels and the AVIF is encoded from those pixels, so the capture date, the camera model and any coordinates stop at the decode step. There is no setting on this page that changes that, because there is nothing in the encoder that would carry them.

For images going onto a public page that is the outcome you wanted, and it needs no second pass. Read the other way it is a loss with no remedy here: if the shooting data mattered, the JPG you started from is the only copy that still holds it, so keep that file rather than expecting the AVIF to give it back.

Drop a folder of up to a hundred and take the results as a ZIP. There is no queue and no daily allowance, because the encoding happens on your own machine.

That machine is also the constraint. AVIF encoding is the most demanding operation on this site, and a hundred large photographs is minutes rather than seconds. Start it and leave the tab open.