Why AVIF encoding is so slow: what we measured at 12 megapixels
The number that changed our defaults
When we were building our image compressor, AVIF was the format that nearly didn’t ship. On a 12-megapixel photo — an ordinary phone or camera image, nothing exotic — a single AVIF encode took 143 seconds at the encoder’s speed 7 setting. Two and a half minutes, for one image, in a browser tab, with a spinner and no way to tell whether it had frozen.
Moving to speed 9 brought the same image down to roughly 40 seconds. That’s still slow, but it’s the difference between a tool people use and a tool people close. speed 9 is what our compressor uses today, and the reason is written into the source right above the call so nobody quietly “improves” it later.
Those are the only two figures we measured, so those are the only two we’ll quote. What follows is why they look like that.
What the encoder is actually doing
AVIF isn’t a still-image format that grew up on its own. It’s a single frame of AV1 video, wrapped in a container. AV1 was designed to compress video streams as hard as computationally feasible, on the assumption that encoding happens once on a server and playback happens millions of times on phones. That asymmetry is baked in: decoding is fast and cheap, encoding is deliberately expensive.
The expense is a search. For every block of the image the encoder can choose among a large set of prediction modes, block partitionings, and transform options, and each combination yields a different size-versus-quality result. Evaluating all of them gives the best answer. Evaluating all of them takes forever. So the encoder exposes a knob — called speed in the library we use, and effort or cpu-used elsewhere — that decides how much of that search space to actually visit.
Low numbers mean a wide search: slower, smaller files. High numbers mean the encoder takes shortcuts, accepting the first reasonable choice instead of hunting for the best one: faster, slightly larger files at the same quality target. It is not a quality slider. The quality setting controls how much detail is discarded; the speed setting controls how hard the encoder works to hit that quality efficiently.
That is the whole trade. Slower settings buy you bytes. How many bytes depends entirely on the image, and since we measured time rather than size across settings, we’re not going to invent a percentage for you.
Why it’s slower in a browser than on your desktop
Run the same encode through a desktop tool and it will usually finish faster than our numbers suggest, for two structural reasons that have nothing to do with the encoder itself.
Threads. Desktop encoders spread the work across every core you have. In a browser, multi-threaded WebAssembly requires SharedArrayBuffer, which requires the page to enable cross-origin isolation via COOP and COEP headers. This site deliberately does not set those headers — cross-origin isolation breaks the ad iframes that pay for the tools being free — so every codec here runs single-threaded by design. Our 143-second and 40-second figures are single-threaded numbers. A four-core desktop encoder working on the same file is not doing less work; it’s doing the same work in parallel.
We get parallelism back a different way: the compressor runs a small pool of independent workers, sized at half your core count and capped at three, dropping to a single worker on mobile or low-memory devices. That speeds up a batch of images. It does nothing for one large image, because a single encode still lives inside one worker.
Memory pressure. AVIF is the heaviest codec in the set, so our compressor never runs two AVIF encodes at the same time even when workers are free. Running several at once on a laptop means memory pressure and a hot machine, and the wall-clock gain is not worth either. Queue a batch of AVIF conversions and they will go through one at a time on purpose.
What we measured
| Setting | Image | Result |
|---|---|---|
| speed 7 | 12 MP | 143 seconds |
| speed 9 | 12 MP | about 40 seconds |
Read this for what it is: two data points from one machine during development, single-threaded WebAssembly in a browser, taken to answer a product question — is this shippable? — rather than to benchmark encoders. Your timings will differ with your hardware, your browser, and the image itself. What generalizes isn’t the seconds; it’s the shape of the curve. A couple of steps on the speed scale can multiply encode time several times over, which is why “AVIF is slow” is less a property of the format than a property of the setting someone chose for you.
It also explains something you may have noticed elsewhere: two tools can both claim AVIF support and behave completely differently, one finishing in seconds and one apparently hanging. They’re likely running the same encoder at different effort settings.
Practical ways to make AVIF exports bearable
- Resize before you encode. Encoding cost tracks pixel count, and most images are exported far larger than they’ll ever be displayed. Halving each dimension is a four-fold reduction in pixels to search through. Our compressor can resize as part of the same pass, and it’s the single biggest lever available.
- Convert one large image at a time, batch the small ones. A pool of workers helps a folder of web-sized images enormously and helps a single 24-megapixel photo not at all.
- Reach for WebP when the wait isn’t worth it. WebP encodes far faster, is supported everywhere, and produces files small enough for most work. Our format comparison walks through when the extra AVIF savings actually justify the encode time, and PNG to WebP handles the common case directly.
- Don’t confuse a slow encode with a slow format. Displaying an AVIF is fast — decoding was the part AV1’s designers optimized. The cost is paid once, by you, at export time. Visitors to your site never pay it.
- Expect a different quality number. In our compressor the default quality is 50 for AVIF against 75 for WebP and JPEG, because the scales aren’t comparable between encoders. Setting AVIF to 75 out of habit produces a much larger file than you intended, not a better-looking one.
Going the other direction
Decoding is where AVIF is genuinely effortless, which is why converting out of AVIF is quick even when converting into it is slow. If someone sent you an AVIF that a client’s older software refuses to open, AVIF to PNG and AVIF to JPG run in a fraction of the time an AVIF export takes — the expensive search already happened, once, on whoever’s machine made the file.
Every one of these conversions runs inside your browser. Your files aren’t sent to a server, which is also why the encode time lands on your CPU rather than someone else’s: there’s no server farm absorbing it. That’s the trade we chose, and publishing the timings we measured seemed a more useful way to explain it than calling the tool fast and letting you find out.