Convert JPG to AVIF — shrink your images 30–50% without visual quality loss

Why convert JPG to AVIF?

Every kilobyte you shave off an image is a kilobyte your visitors never have to download. AVIF compresses 30–50% smaller than JPG at comparable visual quality, which translates directly into real-world wins for site owners. A product gallery that served 4 MB of JPGs can drop to roughly 2 MB of AVIFs with no perceptible difference — cutting CDN egress costs in half and reducing your Largest Contentful Paint time enough to move the needle on Core Web Vitals. Google's ranking signals reward fast-loading pages, and image weight is still the dominant factor on most commerce and editorial sites. Chrome has decoded AVIF natively since version 85 (August 2020), Firefox since version 93 (October 2021), and Safari since version 16 (September 2022), putting AVIF support above 93 % of global browser traffic in 2026. Converting your JPG library to AVIF is one of the highest-ROI performance changes a web developer or site owner can make today.

What you lose and what you gain

Both JPG and AVIF are lossy codecs — each re-encode discards information that cannot be recovered. Converting a JPG to AVIF at quality 75 does not restore any detail the original JPEG encoder discarded; it only wraps what remains in a more efficient bitstream. The practical consequence is that you gain a dramatically smaller file and you do not lose any additional visible quality, provided you pick a sensible AVIF quality level (60–80 is a safe starting range for most photos). What you give up is universal compatibility: tools that predate AVIF — older CMS media libraries, some print services, legacy email clients — will not recognise the .avif extension. The right approach for public-facing images is to serve AVIF to browsers that support it and keep a JPG fallback for the rest, using the HTML <picture> element. For private storage or internal tooling you control, you can go AVIF-only without worrying about fallbacks.

How to convert JPG to AVIF

Everything runs locally in your browser — no upload, no account, no data leaving your machine. The steps below take under thirty seconds for a typical phone photo:

1. Click "Convert to AVIF →" at the top of this page, or drag and drop your JPG file onto the drop zone on the homepage. Multiple-tab batch processing is supported today — open a new tab for each file.
2. Your browser decodes the JPG natively using its built-in JPEG parser, producing a raw pixel buffer in memory. No third-party JPEG library is needed for the decode step because every modern browser ships a fast, optimised JPEG decoder.
3. The raw pixel buffer is handed to a libavif WebAssembly module — specifically the AOM encoder from the Alliance for Open Media — which encodes the image to AVIF. This is the computationally expensive step: libavif's AOM backend is thorough but slow, taking several seconds on a phone for a 12 MP image. Encoding happens in a background Web Worker so the UI stays responsive.
4. A preview of the AVIF appears on screen. Compare it with the original JPG using the before/after slider. Adjust the quality slider (default 75) if you see artefacts you dislike, then re-encode.
5. Click the download button. The AVIF file saves to your Downloads folder with the same base filename and the .avif extension — image.jpg becomes image.avif. Check file size in Finder or Explorer to confirm the savings.

File size comparison: JPG vs AVIF at matched quality

Numbers from a real 4032×3024 iPhone 15 Pro photo (12.2 MP, coastal landscape with sky gradients and fine rock texture). JPG source was exported at quality 90 from Lightroom, then encoded to AVIF at each quality level using the AOM encoder.

When to convert, and when to stay on JPG

Convert to AVIF when you control the delivery environment: your own website, a Jamstack project, a CDN that serves the raw file, or an app where you can confirm the runtime supports AVIF. The payoff — 30–50 % bandwidth reduction and measurably better LCP scores — is substantial enough to justify the encoding time as a build-step asset pipeline task. Do not use AVIF for images that need to open in legacy software. Internet Explorer does not support AVIF at all (or much of the modern web, for that matter). Edge before version 90, macOS older than Ventura on Safari, and most native Windows photo apps prior to the October 2022 update will either show a broken-image icon or refuse to import the file. For public web pages, the safest pattern is the HTML <picture> element: list the AVIF source first, then a JPG fallback. Browsers that understand <source type="image/avif"> grab the AVIF; everyone else silently falls back to the JPG. This gives you the bandwidth savings where it counts without breaking anything for minority user agents. Static-site generators like Astro, Next.js Image, and Nuxt Image handle this automatically when you enable AVIF output, so you may not need to manually convert files at all — just flip a config flag and your build pipeline produces both formats.

Under the hood: which codecs are used

AVIF encoding in this tool is powered by libavif, the reference implementation maintained by the Alliance for Open Media at github.com/AOMediaCodec/libavif. Under libavif's hood sits the AOM encoder (libaom), which is the same codec that Netflix, YouTube, and Apple Photos use for AVIF output. It applies sophisticated in-loop filtering, recursive block partitioning, and film-grain synthesis to achieve its superior compression ratios. The downside is speed: libaom is notoriously slow. Encoding a 12 MP image takes 3–8 seconds on a modern laptop and 20–60 seconds on a mid-range phone — which is why AVIF encoding belongs in a build pipeline or a one-time conversion task, not in a hot path that runs on every page request. The WebAssembly build we ship is the jSquash port maintained at github.com/jamsinclair/jSquash, which compiles libavif + libaom to WASM with Emscripten. JPG decoding uses the browser's native parser — no extra library needed. Both the WASM module and the Web Worker that drives it are cached by the service worker after the first load, so subsequent conversions work fully offline.