AVIF is only worth the trouble in the right place. It is a web format. Browsers all display it, and almost nothing else does, so an AVIF sent to a colleague or a printer is a file they cannot open. Use it where you control the markup and can offer an alternative source.
Encoding happens in your own browser tab. The JPEG is decoded, drawn onto a canvas and handed to the browser's AV1 encoder, with no upload step and no server involved. Client photography and unpublished marketing assets stay exactly where they are.
When converting JPG to AVIF pays off
The gain scales with the size and complexity of the image. Large hero photographs, full width banners and gallery thumbnails all benefit heavily, because AVIF's prediction and entropy coding handle smooth gradients and fine noise far better than the discrete cosine transform JPEG relies on. A 900 kilobyte hero shot commonly lands around 300 kilobytes, which is the cheapest way to reduce image file size across a whole template.
Small images are a different story. Below roughly 10 kilobytes the container overhead and the header cost start to matter, and an AVIF can be no smaller or even slightly larger than the JPEG. Icons and tiny avatars are usually better left alone or moved to a vector format instead.
- Convert hero images, banners and any photograph above roughly 100 kilobytes.
- Convert gallery and product images where total page weight is the problem.
- Convert when you can serve a picture element with a JPEG or WebP fallback.
- Leave small icons and thumbnails as they are, where the saving disappears.
- Leave anything that will be emailed, printed or opened in desktop software.
Which browsers can actually create an AVIF file
Reading AVIF and writing it are separate capabilities, and the gap between them is wide. Chrome, Edge, Opera and every other Chromium browser expose an AVIF encoder through the canvas element. Firefox and Safari display AVIF images correctly but provide no encoder, so a page cannot produce one.
When a browser is asked for a format it cannot encode, it does not raise an error. It returns a PNG under the name you asked for, which is how mislabelled files end up in production and quietly make pages heavier. This tool probes the encoder as the page loads and checks the mime type of every blob it produces.
If you land here in Firefox or Safari, reopen the page in a Chromium browser. There is no JavaScript workaround that adds a codec the browser does not ship, and pretending otherwise would just waste your time.
Quality settings and the cost of a second lossy pass
Your source JPEG has already been through one round of lossy compression, and its artifacts are now part of the image data. Encoding again means AVIF spends bits preserving those artifacts as though they were detail. This is generational loss, and it is the main reason to keep the quality slider higher here than you would when starting from a lossless original.
Between 60 and 70 is the sensible range for a JPEG source. That is high enough that avif compression is not fighting the existing block structure, and still low enough to deliver a substantial saving. Push towards 80 for images with text or hard edges, where any additional smoothing is easy to see.
Always compare the reported output size against the original before committing. If the saving is under about 15 percent, the source JPEG was probably already heavily compressed and converting it again buys little for the compatibility you give up.
How this JPG to AVIF converter works without uploading
The pipeline uses three browser primitives. The File API reads the bytes, the built in JPEG decoder produces pixels, and canvas toBlob asks the AV1 encoder for an AVIF at your chosen quality. Every step runs inside the tab, so there is no request carrying your photograph anywhere.
Expect it to feel slower than other converters. AV1 searches a very large space of possible encodings, and that search is exactly what buys the smaller file. A single large photograph can take a second or more, and a batch of thirty is measured in tens of seconds rather than milliseconds.
Serving AVIF with a fallback so nothing breaks
Because installed browser versions lag behind current ones, ship AVIF through a picture element with source entries in order of preference: AVIF first, then WebP, then the original JPEG in the img tag. The browser picks the first type it understands and ignores the rest, so no visitor sees a broken image.
The same reasoning applies to email and social previews. Mail clients and some link unfurlers do not understand AVIF at all, so open graph images and newsletter artwork should stay as JPEG even when the page itself has moved on.
| Format | Relative size | Encoded in browser | Opens outside a browser |
|---|---|---|---|
| JPG at quality 85 | 100 percent | Everywhere | Everywhere |
| WebP at quality 80 | 70 to 75 percent | Everywhere | Recent software only |
| AVIF at quality 65 | 40 to 60 percent | Chromium only | Rarely |
How to convert JPG to AVIF
- 1
Confirm your browser can encode
The page tests the AVIF encoder on load. If it reports no support, open the page in Chrome, Edge or another Chromium browser.
- 2
Add your JPG photographs
Drop one or more .jpg or .jpeg files onto the panel, or click to browse. They are read from disk locally.
- 3
Set the quality
Start at 65 for a JPEG source, which is already lossy. Raise it towards 80 for images containing text or hard edges.
- 4
Convert, compare, download
Press convert, check the before and after sizes, then download individually or take the whole batch at once.
Related tools worth bookmarking
Sources and further reading
- MDN: HTMLCanvasElement.toBlobExplains the quality argument and the PNG fallback a browser returns for a type it cannot encode.developer.mozilla.org
- AOMedia: AV1 Image File Format specificationThe specification behind AVIF, published by the Alliance for Open Media that also defines AV1.aomediacodec.github.io
- ITU-T T.81: the JPEG standardThe original JPEG specification, which defines the block based coding whose artifacts carry into a re encode.w3.org
Frequently asked questions
Common questions about the jpg to avif converter.
Between 40 and 60 percent is typical for photographs at matching visual quality. Images that were already saved at low JPEG quality save much less, and very small files can come out slightly larger because of container overhead.
Slightly, yes. The JPEG artifacts already baked into your file are treated as real detail by the AVIF encoder, so a second lossy pass compounds the first. Keeping quality at 60 or above makes the difference very hard to see.
AV1 encoding is computationally expensive by design, because the exhaustive search for an efficient representation is what produces the small file. The work runs on your own processor, so speed depends on your hardware rather than a shared queue.
Not reliably. Mail clients, office suites and most desktop image software still cannot open AVIF, so a recipient may see nothing at all. Send a JPEG for anything that leaves a web page and keep AVIF for site delivery.
No. Decoding and encoding both happen in your browser using the canvas element, so nothing is transmitted, stored or retained anywhere. Open the network panel of your developer tools during a conversion to confirm it stays silent.