Notes from the team on craft, formats, and the small decisions behind a good round crop.
Why AVIF encoding runs slower than the rest
The foundation under AVIF is the AV1 video codec and its intra-frame compression. AV1 was tuned to wring out the best compression ratio rather than the quickest encode, so it reaches for costlier prediction modes, larger transforms, and trickier in-loop filters than either JPEG or WebP. What runs here is a software build of that encoder, living inside the browser. Feed it a 1024 by 768 image and the encode lands near 250 milliseconds once warm on Chromium desktop, or near 1.1 seconds cold with the warm-up folded in. Take it up to 8 megapixels, 3840 by 2160, and it climbs to about 2.8 seconds on Chrome and about 31 seconds on Firefox, which treads more carefully through this code. Mid-range phones run perhaps 3 to 5 times the desktop number. All of that is precisely why the interface never sells an AVIF run as instant. Workable for one photo, slow enough that an honest progress state belongs on screen.
What choosing AVIF output sets in motion
AVIF asks more of the machine than anything else this tool makes, so to hand you the smallest, sharpest file Araluma may run the encode on our server with a quick native build, and turning several into AVIF at once always runs there. The files involved are cleared within about 2 hours, and a wipe is one tap away. When that route is down, a compiled AVIF encoder loads once in the tab, roughly 870 KB compressed, and the encode finishes locally as a backup. None of this touches the PNG, JPG, and WebP pairs, which ride the browser's own codecs. The extra effort is simply what AVIF charges for its size win.
How AVIF outdoes JPEG at matching quality
Block-based prediction is AVIF's core trick, borrowed from how modern video codecs operate. For every block of pixels, the encoder weighs a handful of prediction modes, directional, smooth, and DC, against the neighbours it has already encoded, then settles on whichever leaves the smallest remainder. Only that remainder is transformed and quantised, never the raw pixel values themselves. The payoff is reading local structure far more efficiently than JPEG's stiff 8 by 8 DCT, which lays the same transform geometry across the whole frame no matter what it shows. Where a gradient runs smooth, AVIF's prediction can rebuild the patch leaving almost nothing behind. Over skin, hair, and sky it repeatedly turns out a smaller file than JPEG or WebP at visually equal quality. The toll is encode complexity, since weighing many modes per block burns real cycles, which is why AVIF counts in seconds where JPEG counts in milliseconds.
Core Web Vitals: AVIF hero images and LCP
How fast does the largest visible element finish loading in the viewport? That is what Largest Contentful Paint measures, and on most landing and product pages the element in question is the hero photo. Google has stated outright that Core Web Vitals act as a Search ranking signal. Put a 300 KB hero JPEG on a 3G link and it needs about 2.4 seconds. Swap in the same image as AVIF at standard quality, perhaps 100 KB, a 67 percent cut, and the LCP share drops to around 0.8 seconds on that link. That shift carries LCP from the red beyond 2.5 seconds into the green beneath it, a meaningful gain for Search. Every image on the page compounds the saving. CDNs that negotiate format on their own, Cloudflare, Fastly, Akamai, read the Accept header and serve AVIF to capable browsers once the AVIF originals sit in the library.
AVIF in 2026: support, readiness, and the gaps
Where does AVIF stand at mid-2026? On the browser front it is settled, decoding wherever Chrome has reached 85, Firefox 93, Edge 121, or Safari 16.4 on iOS 16 and macOS Ventura, which sums to roughly 94 percent of all traffic. The missing 6 percent leans on iPhones that never moved past iOS 15, a build Apple has stopped enriching, with Internet Explorer alongside. So for reaching consumers broadly, the web half of the story is done. The unfinished half is the software ecosystem. Adobe brought AVIF export to Lightroom at 13.3 in 2024, Serif's Affinity Photo has read and written it since 2.3, while the stock-photo libraries largely still bounce AVIF submissions. The print trade, for its part, has not budged off JPEG and TIFF. Read it as web-ready, then, but tuck a JPEG master aside whenever a workflow hands files to systems beyond your reach.
Weights side by side: AVIF, WebP, and JPEG
Our benchmark leans on three real-world fixtures, and run at standard quality it tells a tidy story across the formats. The small case is a 1024 by 768 photo that weighs 17 KB in JPEG. Recoded, it falls to 7.3 KB as WebP, a 57 percent trim, and to 6.0 KB as AVIF, a 65 percent trim. The large case is a 3840 by 2160 photo at 116 KB in JPEG. That one drops to 32 KB as WebP, off by 72 percent, and to 16 KB as AVIF, off by a full 86 percent. The pattern is plain enough. AVIF opens a wider lead over WebP precisely as photos climb in resolution and pixel density. Reverse course to a tiny 400 by 300 frame, all of 0.12 megapixels, and the lead shrinks while encode overhead eats a larger fraction of the wall-clock time. None of these numbers come from a vendor sheet. They are ours, and any individual photo will drift with its own complexity, noise, and colour range.
