Convert JPG to AVIF
Re-encode a JPEG as AVIF, which costs seconds of processor time and usually returns about half the bytes.
How it works
The cost of AVIF is search. libaom's encoder does not compute one answer per block; it trials a great many, codes each candidate, scores it and throws almost all of them away. That machinery was built for video, where the expense is spread over frames that mostly resemble one another. A still photograph has no previous frame to lean on and pays the whole search by itself.
The bill is measurable. On an Intel Core i7-12700KF on 6 August 2026, a 3000×2000 photograph took 4.67 seconds to encode at the default effort. The same decoded pixels went through mozjpeg in 0.75 seconds and through libwebp in 0.57 seconds. Eight times the cost of a WEBP encode is the entry price, and it is charged once per image.
What the effort control actually trades
Effort is libaom's speed parameter, and the scale runs backwards: the three settings offered are speed 8, 6 and 4, where the lower number searches harder and takes longer. Spending more of it does not shrink the file. On that six-megapixel photograph at quality 65, Fast produced 257,306 bytes in 1.64 seconds and Thorough produced 294,695 bytes in 46.01 seconds: fifteen per cent larger, for twenty-eight times the wait.
The extra search buys a better decision at a fixed quantiser instead. Measured on a 1600×1200 photograph at quality 65, the three settings scored 41.93, 43.04 and 43.37 dB PSNR against the source's own decoded pixels. Fidelity climbs and the byte count climbs with it, because the encoder spends whatever its rate-distortion model says the recovered detail is worth. Turning effort into a smaller file means lowering the quality number as well.
Choosing a quality number
AVIF's scale is not JPEG's and the digits do not transfer. On the 1600×1200 photograph, a 137,856-byte JPEG came back as 66,579 bytes at quality 65, as 99,948 bytes at quality 80, and as 32,646 bytes at quality 50. That is a spread of three to one across three settings that all sound sensible said out loud.
So the honest way to choose is to convert twice and look at the two results at the size they will actually be seen, rather than copying across the number you use in an image editor. Each run reports its own byte delta, and two runs on a two-megapixel photograph cost about three seconds between them.
What the saving depends on
Content moves the delta further than the settings do. The 1600×1200 photograph gave up 51.7 per cent of its bytes at quality 65. A screenshot of a Wikipedia article at 1024×768, converted at identical settings, gave up 30.7 per cent, because anti-aliased text is expensive for every lossy codec and the source JPEG had already spent 1.36 bits per pixel on it. Photographs gain most, interface captures and line art least.
One thread, no exceptions
jSquash ships a threaded build of libavif beside the single-threaded one and picks between them by feature-detecting WebAssembly threads. Threads need SharedArrayBuffer, SharedArrayBuffer needs cross-origin isolation, and this site does not send those headers, so the threaded binaries are stripped from the deployment and the detection always returns false.
Every figure on this page came out of that same single-threaded code path, so they describe what the browser does rather than what a build server could do. A faster or slower processor moves them roughly in proportion, and the rate is close to linear in pixel count.
Who will not be able to open the result
A smaller file the recipient cannot see is a worse file. On Windows, the Photos app and File Explorer show nothing for an AVIF until Microsoft's AV1 Video Extension has been installed from the Store; without it Explorer draws a generic document icon in place of a thumbnail. GIMP has read and written AVIF only since 2.10.22, released on 7 October 2020. Adobe's February 2022 Photoshop release, version 23.2, added full WEBP support and no AVIF.
Upload forms are the other trap, because a great many validate the extension rather than the bytes and .avif is absent from their lists. AVIF repays its encode time on a hero image compressed once and served a million times. For a thousand images this afternoon, or for a file about to be attached to an email, it does not.
Questions
How long will the encode take?
Roughly 0.8 seconds per megapixel at the default Balanced effort, measured on an i7-12700KF: 1.73 seconds for a 1600×1200 photograph and 4.67 seconds for a 3000×2000 one. Fast is about a third of that. Thorough is about ten times it, and took 46.01 seconds on the six-megapixel file.
Which effort setting should I pick?
Balanced, unless you have a reason. Fast is the right choice for anything converted in quantity: on both test photographs it came out 5 to 8 per cent smaller than Balanced at the same quality number, in a quarter to a third of the time, and scored 41.93 dB PSNR against Balanced's 43.04 on the 1600×1200 file. Thorough is worth its 46 seconds only for a single image that will be served for a long while, and even then it returns a larger file rather than a smaller one.
The progress bar stopped moving. Has it frozen?
No. The encode is one call into WebAssembly that runs to completion without yielding, so there is no intermediate point at which progress could honestly be reported, and Cancel cannot interrupt it once it has started. The work happens in a Web Worker on your own machine, which is why the rest of the page stays responsive and why the Network tab shows no request carrying your image.
What if the person I send it to cannot open it?
Convert it back. AVIF to JPG and AVIF to PNG both accept this tool's output and are offered as the next step, so nothing is stranded in a format the recipient lacks a decoder for. Keep the original JPEG as well: converting AVIF back to JPEG is a third lossy generation, and the first file is always better than a round trip.