I'm the person who built this site. Not a team, not a company — just me, a side project that got bigger than I expected. And because I'm the one maintaining the converter, I've had a front-row seat to what image formats actually do in the real world. This isn't a repost of a benchmark. It's what I personally ran into.
About a year ago I got tired of uploading images to random websites and wondering what happened to them afterward. So I built my own local converter — one where the file never leaves your browser. While I was at it, I started obsessing over which format was actually worth recommending. WebP was the obvious answer in 2022. But AVIF kept coming up, and I wanted to see for myself.
Over the past several months I've run conversion tests on hundreds of real images — not stock photos picked to make numbers look good, but the kinds of things people actually upload: product shots, travel photos, screenshots, and the occasional 40MB RAW file someone definitely should have resized first.
AVIF came out of video compression research. The same people who figured out how to stream 4K video on a mediocre internet connection turned those techniques toward still images. The result is a format that's genuinely smarter about how it stores color and detail — especially in gradients, skin tones, and anything with a smooth background.
It supports HDR, 12-bit color, and transparency. Those aren't marketing buzzwords — they matter if you're dealing with professional photography or trying to replace PNG with something smaller. But here's the thing nobody mentions: it's also significantly slower to encode than WebP. I'll come back to that.
The benchmark articles you'll find online love to say "AVIF is 50% smaller than JPG." That's true sometimes. Here's what I actually saw across different image types:
The gap is real, but it's not magic. It depends heavily on what you're converting.
When I tried to add AVIF conversion to this site, it was painfully slow. A 3MB photo was taking 8–12 seconds to process in a browser tab. That's not something you can ship — users will close the tab before it finishes.
The root issue is that AVIF encoding is computationally heavy. It was designed assuming you'd run it on a server with time to spare, not inside a browser tab. JavaScript alone can't handle it without serious optimization work.
The obvious path forward is WebAssembly (WASM) — compiling a library like libavif to run at near-native speed in the browser. I started looking into that approach. It got complicated fast: color profile edge cases, memory issues on lower-end devices, artifacts on some image types. I got stuck, other parts of the project needed attention, and I decided I'd rather wait and ship something reliable than rush it out. AVIF conversion is still not available on this site.
Your file goes to someone else's computer. Fast for the user, but you're trusting a stranger with your images. The site owner sees them regardless of their privacy policy.
Conversion happens entirely in your browser using your device's CPU. Nothing leaves your machine. I have no way to see your files — technically, they never reach me.
Browser support crossed 93–94% of global users sometime in 2025. For most sites, that's probably good enough — especially if you're using a proper fallback.
The HTML pattern I'd actually recommend using today:
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="Your image" loading="lazy"> </picture>
This way, modern browsers get AVIF. Slightly older ones get WebP. Ancient ones (and some corporate browsers behind IT restrictions) get JPG. Nobody gets a broken image.
AVIF conversion isn't available on this site. I tried to build it, ran into encoding performance problems in the browser that I haven't fully worked through, and decided not to ship something unreliable. WebP conversion works well and covers the majority of use cases anyway.
If you specifically need AVIF today, Squoosh by Google handles it and also runs entirely locally in your browser. That's the tool I'd point you to.
I get asked this a lot, so I'll say it plainly. When you use this converter, your image is processed entirely by your own computer's CPU. It's not uploaded anywhere. I have no database of user images, no training dataset, nothing like that. The WASM file loads once, runs locally, and that's it.
I built it this way because I wanted to use it myself without worrying. That's still the main reason it works this way.
For photos with smooth areas and gradients, yes, noticeably. For screenshots, UI graphics, or highly textured images, it's less clear-cut. Run your own test — the difference is real but context-dependent.
No. I tried building AVIF encoding and ran into encoding performance and reliability problems in the browser that I haven't resolved. For AVIF conversion right now, Squoosh by Google is the best local browser option.
Yes, full alpha channel. In theory you can replace PNG entirely with AVIF and save a lot of space. In practice, test it on your specific images first — the quality difference at equivalent file sizes can vary.
Use the <picture> element with fallbacks shown above. It takes 5 minutes to add and means nobody gets a broken image.
If you found this useful or have questions about specific image types you've been struggling with, feel free to reach out via the contact page. I read every message, even if it sometimes takes me a few days to reply.