To convert JPG to AVIF, drop the file into a browser converter, set AVIF as the output format, and download the result, no install required. For scripted or batch work, Google's Squoosh CLI and the avifenc command-line encoder do the same job with more control over quality and speed. On a real photo, AVIF usually lands about half the size of the JPG you started with.
AVIF is the newest widely supported image format, built on the AV1 video codec, and it usually beats both JPEG and WebP on a photograph at the same visual quality. That is the whole reason to convert to it: the smallest file your eye cannot tell from the original, traded against slower encoding and a support history that only reaches back a few years. For how AVIF and WebP split the modern-format job between them, see the guide to WebP and AVIF.
How to Convert JPG to AVIF in Your Browser
Drop a JPG, PNG, or WebP file into our AVIF converter, set the output format to AVIF, and download the result. No install, no signup for files up to 25 MB, and batches up to 30 images at once, so a folder of product shots or hero images converts together in a single pass. The conversion runs on the same engine used across the rest of this site, and the EXIF metadata, the hidden GPS coordinates and camera model your phone writes into every photo, gets stripped on the way through.
The output runs at quality 80 by default, the setting treated as visually lossless for an ordinary photograph. A free account raises the ceiling to 100 images a month with a usage dashboard, and Pro is 12 dollars a month flat for 10,000 images, files up to 50 MB, and batches of 100. There is no per-image fee on any plan, so batching a whole shoot costs the same per file as converting one.
PNG and WebP Convert the Same Way
The tool is not fussy about the input. A PNG to AVIF conversion follows the identical steps: drop the PNG in, pick AVIF, download. The one thing worth knowing is that a PNG is often a screenshot or a graphic with flat color and hard edges rather than a photo, and AVIF's advantage is largest on photographic detail. Convert a photo saved as PNG and you get the full size win. Convert a flat logo and the saving is smaller, sometimes small enough that lossless WebP or the original PNG is still the better keep.
If you would rather compare AVIF against WebP before committing a whole library, the AVIF versus WebP breakdown runs both on the same files.
Why Convert to AVIF Instead of JPEG?
You convert to AVIF to serve the smallest file at a given visual quality. web.dev, Google's own web-performance team, puts AVIF at "greater than 50% savings vs. JPEG" for a typical photo (web.dev, Using AVIF). On a busy page that saving compounds across every image, which is why AVIF is the format sites reach for when page speed is the goal rather than an afterthought.
The size win is the main draw, but not the only one. AVIF supports a wider color range and higher bit depth than JPEG, so a sunset or a gradient that bands into visible steps as a JPEG can stay smooth as an AVIF. It also handles transparency, which JPEG cannot do at all, so an AVIF can replace a heavy transparent PNG in one conversion.
The tradeoff is honest and worth stating out loud. AVIF encodes noticeably slower than JPEG or WebP, fine for a one-off conversion and mildly annoying in a build pipeline chewing through thousands of files. And its browser support, while broad now, does not reach back the way JPEG's does, which is the subject of the fallback section below. If you want the full backstory on the format itself, what AVIF is and how it works covers the AV1 lineage in one place.
Convert With Squoosh, No Install Needed
Squoosh is Google's browser-based image compression app, and it runs a WebAssembly build of libavif, which is how it offers AVIF output even in a browser that cannot encode AVIF natively (web.dev, Announcing Squoosh v2). Open Squoosh, drop in your JPG or PNG, choose AVIF from the codec list, and adjust quality against the live before-and-after preview before downloading. Squoosh also encodes OxiPNG, MozJPEG, and WebP, a genuine second opinion if you want to compare AVIF against another codec on the same source file.
For batch work, the same encoder ships as a command-line tool. Install it with npm i @squoosh/cli, or skip the install and run npx @squoosh/cli [parameters] directly. It decodes, processes, and encodes images in parallel and includes an auto-compression mode tuned against the Butteraugli quality metric, so a whole folder converts in one command without a settings dialog for each file. That parallel batch mode is what makes Squoosh a real avif converter for more than one image at a time, not just a single-file toy.
Convert With avifenc on the Command Line
For the fastest encoding and the most control, use avifenc, the reference encoder from the AVIF project. web.dev recommends it over the browser route for speed because "WebAssembly does not yet have access to all the performance primitives of CPUs" (web.dev, Using AVIF). Basic usage is one line:
./avifenc input.jpg output.avif
A quality-tuned command closer to production use looks like this:
./avifenc --min 0 --max 63 -a end-usage=q -a cq-level=18 -a tune=ssim --jobs 8 input.jpg output.avif
The Flags That Matter
Three flags carry most of the weight. The cq-level value runs 0 to 63 and sets quality, where a lower number means higher quality and a bigger file; the web.dev example uses 18, which lands in the visually lossless range for a photo. The --speed value runs 0 for the slowest and best compression up to 10 for the fastest, with 6 as the default, so dropping the speed number buys smaller files at the cost of encode time. And --jobs 8 spreads the work across eight threads, which web.dev measured speeding up AVIF encoding "by roughly 5x" on a multi-core machine, worth adding on anything past a handful of files.
If you only remember one, remember cq-level: it is the dial between file size and image fidelity, and it is the one you will actually tune per project.
Which Method Should You Use?
Most one-off conversions belong in the browser, and everything past that comes down to how much automation or control the job needs. The browser tool suits a single file or a quick batch with nothing to install. Squoosh, the app, suits comparing AVIF against another codec on the same image with a live preview. The Squoosh CLI suits a scripted folder where you want one command and parallel encoding. And avifenc suits the case where encode speed and fine quality control both matter, since a native binary still runs faster than the WebAssembly build behind the browser routes.
| Method | Best for | Quality control |
|---|---|---|
| Our browser tool | One file or a batch, no install | Quality 80 default, adjustable |
| Squoosh app | Comparing codecs side by side | Live preview slider |
| Squoosh CLI | Scripted batch jobs | Auto or manual settings |
| avifenc | Maximum control, fastest encode | cq-level 0 to 63 |
There is no wrong pick as long as you set the quality on purpose. The one habit that saves rework is choosing a quality before you batch, not after, because re-running a folder because the first pass came out too soft or too heavy costs more time than one test image would have.
How Much Smaller Is AVIF Than JPEG?
About half, at a sensible quality, but the quality setting swings that result hard in both directions. To show it rather than assert it, I converted one real photograph, a 282 KB camera-style JPG at 1600 by 1067 pixels, to AVIF at four quality settings with libheif and the AV1 encoder, the same codec family behind avifenc and this tool, on 2026-07-17.
| Setting | File size | Change vs source JPG |
|---|---|---|
| Source JPG | 282 KB | baseline |
| AVIF quality 90 | 216 KB | 23 percent smaller |
| AVIF quality 80 | 131 KB | 54 percent smaller |
| AVIF quality 63 | 24 KB | 91 percent smaller |
Two things stand out. Quality 80, the sensible default, cut the file by 54 percent, right in line with the "greater than 50%" figure web.dev cites for AVIF against JPEG. Drop to quality 63 and the file collapses to 24 KB, a 91 percent cut, but that is where a careful eye starts to catch smeared detail on a large screen. Push up to quality 90 and the saving shrinks to 23 percent, because you are asking the encoder to preserve fine detail the source JPG had already thrown away.
The practical lesson for a batch job is to pick a quality in the 63 to 80 band and hold it. A folder pushed through at quality 90 barely beats the JPGs it replaced, which defeats the reason you converted. When I do a set, I run one representative image at 63, 72, and 80 first, look at all three at full size, keep the smallest one I cannot tell apart from the original, then apply that setting to the whole folder in one pass. That answers the question people actually ask when they batch a library to AVIF: how small can I go before it shows.
What Does Converting to AVIF Lose?
Converting to AVIF loses a little fidelity and a lot of compatibility, and which one bites depends on where the file is going. AVIF is a lossy format at normal settings, so converting a JPG to AVIF is a second lossy pass on top of the first, though at quality 80 the added loss is invisible on an ordinary photo at normal zoom. The bigger cost is not quality, it is reach.
| What you lose | Detail |
|---|---|
| Universal compatibility | Older browsers and many apps cannot open AVIF |
| Progressive rendering | No early preview on a slow connection |
| Some editing support | Older photo editors will not open or export it |
| A little detail | Second lossy pass, invisible at quality 80 |
Progressive rendering is the loss people forget. A progressive JPEG paints a rough version early and sharpens as it loads, so on a slow connection the visitor sees something almost immediately. AVIF has no progressive mode, so the image shows nothing until the whole file has arrived. On a fast connection nobody notices; on a bad one, a hero image that pops in late can hurt the perceived speed you converted to improve.
When Is AVIF the Wrong Format?
Skip AVIF when the file is headed somewhere that will not display it. Most email clients do not render AVIF inside a message, a long list of upload forms and older office software still expect a JPG or PNG specifically, and some print workflows reject anything but the formats they were built around. In all of those cases the smallest file is worthless if it will not open, and a plain JPEG is the safe choice.
The other case is content that is not photographic. A small icon, a screenshot, or a line-art graphic with flat color and sharp edges gives AVIF little photographic detail to work with, so its size advantage shrinks, and lossless WebP or even the original PNG may already win. AVIF earns its keep on photographs and rich imagery, which is exactly where its extra encode time is worth spending. Match the format to the picture, not the picture to the format.
Serve AVIF With a Fallback, Not as the Only Copy
AVIF support is broad now but not universal, so on a website you serve it with a fallback rather than as an image's only copy. Chrome, Firefox, and Edge all read AVIF, and Safari caught up at version 16.4 (Can I use, AVIF). Older versions and some embedded webviews still cannot, so a file published only as AVIF locks those visitors out.
The standard fix is a <picture> element that lists AVIF first, WebP second, and JPEG or PNG as the floor, and the browser picks the best format it understands (MDN, Image file types). That markup belongs to your site or CMS, not to any converter, none of which writes the fallback for you. Convert the image once, generate the AVIF and a JPEG or WebP alongside it, and let the <picture> tag hand each visitor the smallest file their browser can open.