Where AVIF files come from
An AVIF on your computer almost always arrived from a website. Image delivery networks such as those used by large publishers, shops and social platforms detect a modern browser and send AVIF instead of JPG, and when you save the picture, that is what you get. Some Android phones and screenshot tools have started producing it directly, and a few AI image services deliver their output in it. Then you try to send the file to a print lab, open it in an older photo editor, upload it to a marketplace or attach it to a form, and it is refused. JPG is refused nowhere. That is the whole reason for this page.
The browser has to decode it first
Unlike most conversions on this site, this one depends on your browser being able to read the input. There is no separate AVIF decoder in the tool; the file is opened by the browser's own image pipeline and the raw pixels are then passed to a Web Worker for encoding with mozjpeg compiled to WebAssembly. Chrome and Edge have decoded AVIF since 2020, Firefox since version 93, and Safari since 16.4 on macOS 13 and iOS 16.4. On anything older the tool reports a failure immediately rather than producing a broken file. Nothing is uploaded either way.
What is lost in the conversion
- Transparency. AVIF supports an alpha channel and JPG does not. The encoder drops the alpha, and fully transparent pixels typically end up black. For a graphic with a transparent background, use AVIF to PNG instead.
- Bit depth and HDR. AVIF is commonly 10-bit and may carry HDR or wide-gamut colour. The canvas decode reduces it to 8-bit sRGB, so extreme highlights are clipped and very saturated colours are pulled in slightly. For a normal web photo this is invisible; for an HDR photo from a recent phone it is not.
- Quality. AVIF is lossy, and JPG re-encodes it lossily. The two codecs degrade in different ways: AVIF smooths, JPG rings around edges. At a decent quality setting the combination is fine, but it is one more generation of loss.
- Animation and metadata. An animated AVIF contributes only its first frame. EXIF, XMP and the colour profile are not carried over.
Quality, and why the JPG will be bigger
The slider runs from 20 to 95 and defaults to 80. Since the input is already compressed, 85 to 90 is the sensible range; the extra bytes stop the two codecs' artefacts from stacking visibly. Because JPG is the far less efficient codec, expect the file to grow considerably:
- A 1920x1080 article image of 95 KB as AVIF usually comes out around 300 to 450 KB as JPG at quality 85.
- A 1200x1200 product photo of 60 KB as AVIF typically lands between 180 and 260 KB.
- A 4000x3000 photo of 700 KB as AVIF often becomes 2 to 3 MB.
These are typical figures, not guarantees. The result is a progressive JPG at the original pixel dimensions; if you also need it smaller for an upload limit, Compress image can resize and target a specific file size.
When to leave it as AVIF
If the image is going onto a website, keep the AVIF and add a JPG only as a fallback; you would be trading a small file for a large one. If it needs editing later, decode it once to PNG rather than JPG so that no further quality is lost while you work. And if the AVIF is an HDR photo you care about, converting to JPG is a one-way trip to standard dynamic range, so keep the original. For the wider picture on where each format is safe to use, see WebP vs AVIF vs JPEG.
The remaining limit is memory: a very large AVIF decodes to a big canvas, and on a phone the browser may refuse beyond a few tens of megapixels.