AVIF Converter
Encode to AVIF for the smallest files modern browsers accept. Up to 5 images per batch.
How to use
Load up to five images
The browser decodes each one and prepares a lossless PNG intermediate, which is what gets sent to the encoder. Sources can be PNG, JPEG or WebP.
Pick a quality target
AVIF holds up at settings that would visibly damage a JPEG. Somewhere between 50 and 65 is a reasonable starting point for photographs.
Encode and collect the ZIP
Requests are queued rather than fired all at once. If the encoder is busy the page pauses, shows a countdown and resumes on its own.
Key Features
The best compression available
AVIF consistently produces smaller files than WebP at matched quality, with the advantage growing at aggressive settings. For large hero images the saving can be the difference between one network round trip and three.
Graceful at low bitrates
Where JPEG breaks into visible blocks and WebP smears into a waxy texture, AVIF holds edges and fine detail together. It fails softly, which matters when you are optimising aggressively.
High bit depth and wide gamut
Ten and twelve bit encoding is supported, along with wide colour primaries and HDR transfer functions. Gradients that band visibly in 8-bit formats stay smooth.
Server-side encode, plainly stated
Unlike the WebP and PNG tools, AVIF encoding runs on this application's server because AV1 is too heavy for a browser tab. Images are processed in memory for the length of the request and never stored.
Queued and rate limited
Requests go through a client-side queue that respects the encoder's limits. If it returns a rate limit response the batch pauses, counts down and retries automatically instead of failing the whole run.
Validated on both ends
Files are checked by magic bytes in the browser and checked again on arrival at the encoder, which accepts only PNG. Anything else is refused before it reaches the codec.
Frequently Asked Questions
Does my image get uploaded for AVIF?+
The image lives in memory for the duration of the request. It is not written to disk, not logged and not retained. Every other tool here, including background removal, runs entirely on your device.
Which browsers can display AVIF?+
Why does encoding take so long?+
Is AVIF always the right choice?+
What does the countdown mean?+
Can I encode more than five at once?+
Format Comparison
| Feature Specification | AVIF encoding | Alternative |
|---|---|---|
| Size at matched quality | 20 to 50 percent below WebP | Baseline |
| Encoding speed | Seconds per image | Near instant |
| Bit depth | 8, 10 or 12 bit | 8 bit |
| Browser support since | Safari 16.4, March 2023 | Safari 14, September 2020 |
| Where it runs | This site's encoder | Entirely in your browser |
Technical Overview & Specifications
Deep dive into AVIF encoding architecture and processing.
Show DetailsHide Details
Technical Overview & Specifications
Deep dive into AVIF encoding architecture and processing.
Platform Overview
AVIF is what you reach for when WebP is not small enough. It is the still-image profile of AV1, the video codec that Netflix, YouTube and most of the streaming industry moved to, and it inherits a decade of compression research that JPEG and WebP predate. In practice AVIF lands somewhere between twenty and fifty percent below a WebP file of equivalent visual quality, and the gap widens as you push the quality down. At genuinely low bitrates, where JPEG has collapsed into blocks and WebP has gone soft and waxy, AVIF is still producing something a person would accept. It also handles things the older formats cannot: ten and twelve bit colour depth, wide gamut, and HDR.
The catch is encoding cost. AV1 gets its results by searching an enormous space of possible encodings, and that search is slow and memory-hungry in a way that does not fit comfortably in a browser tab. So this page works differently from the others: the browser prepares a clean PNG of your image, sends it to this site's own encoder, and receives the AVIF back. Your file does go over the network, to this application and nowhere else, and it is held only for the duration of the request. It is not written to disk, not logged, and not retained. If that trade is not acceptable for a particular image, the WebP converter will do the whole job locally and get you most of the way there.
The split between browser and server
The browser does the preparation. Your file is validated, decoded, cropped and scaled according to whatever settings you have chosen, and then written out as a lossless PNG. Lossless matters here: sending a JPEG intermediate would bake that JPEG's artefacts into the AVIF and waste bits describing them. The PNG is posted to the encoder endpoint along with your quality setting. On arrival the bytes are checked against the PNG signature before anything else touches them, which is a cheap guard against a malformed or mislabelled payload reaching the image library.
Encoding itself uses sharp, which wraps libvips and libaom, at effort level 4 with 4:2:0 chroma subsampling. Effort 4 is a deliberate middle setting: pushing it higher shaves a few more percent off the file but multiplies the time per image, and at some point a user staring at a spinner costs more than the bytes are worth. Chroma subsampling at 4:2:0 discards three quarters of the colour resolution while keeping full luminance detail, which is nearly invisible on photographic content and is the same trade JPEG has been making since 1992. The encoded buffer is returned directly in the response body and the client drops it straight into the ZIP alongside anything that was encoded locally.