AVIF vs JPEG XL vs WebP — measured on your image

Every image-format benchmark on the web answers the same question for the wrong image: *theirs*. A corpus of test photos, encoded once on one machine, produces the charts you have seen everywhere — and none of them tell you what happens to your product shot, your screenshot, your 45-megapixel export. This page flips it: you drop an image, and AVIF, JPEG XL, WebP, and the browser’s own JPEG encode it right here, in your tab. Sizes, encode times, decode times, and pixel-level difference — measured on your machine, against your file, in about the time it takes to read this paragraph.

Nothing is uploaded. The encoders are real codec engines — rav1e for AVIF, the reference libjxl, libwebp — compiled to WebAssembly and served from this site’s own domain, fetched once and cached; your image never leaves the tab, which you can verify in DevTools or by going offline after the page loads. For the corpus-scale picture this page cannot give you (hundreds of photos, perceptual metrics, HDR), the best published benchmark is Jake Archibald’s October 2026 AVIF-vs-JPEG-XL study, and this article leans on it for the landscape — then hands you the tools to check its conclusions against your own images, which is exactly what that study’s own closing advice asks you to do.

Frequently asked questions

Is AVIF or JPEG XL smaller?

For lossy photos, AVIF usually wins — the October 2026 jakearchibald.com benchmark (the current reference work) found the best JPEG XL encodes 6–25% larger than AVIF at similar quality, with occasional photos where JPEG XL wins instead. For lossless, JPEG XL clearly wins: WebP was 9–17% larger and lossless AVIF 30–120% larger in the same study. The honest answer is image-dependent, which is why this page lets you measure both on your own file instead of trusting a corpus average.

Which image format is best in 2026?

For shipping photos on the web: AVIF at 4:4:4 chroma with a WebP or JPEG fallback — smallest at like quality, decoded by every current browser, and hardware-decoded on recent phones. JPEG XL is the capability choice: best lossless compression, lossless recompression of existing JPEGs, and it catches up to (or beats) AVIF at very high quality settings. WebP remains the conservative middle with the widest legacy support. Run your actual image through the comparison above — the deltas for a specific image regularly disagree with the averages.

Is JPEG XL supported in browsers now?

As of October 2026, yes in the majors: Chrome 155 (released October 6, 2026) decodes JPEG XL natively on desktop, Safari has since version 17 (2023), and Firefox is expected to ship it in version 157 around November 2026. Until your audience fully catches up, serve JXL with a fallback — and for converting the files everything else cannot open yet, the JXL to JPG converter here runs entirely in your browser.

What is a good PSNR for image compression?

As a rough tripwire for photos: 35–40 dB means visible differences under scrutiny, 40–45 dB is the well-tuned sweet spot for q75-class encodes, and above ~50 dB most people cannot find the difference even when flipping. But PSNR is a strict mathematical metric, not a perceptual one — professional benchmarks use SSIMULACRA2 or ColorVideoVDP, which themselves often disagree. Treat PSNR as the signal to hold-to-compare with your own eyes, which is exactly what the preview above is for.

Why does JPEG XL decode slower than AVIF?

Codec design: AVIF reuses the AV1 video codec’s decode path (with hardware support on modern phones), while JPEG XL’s decoder is a new design that in the October 2026 benchmark took 2–3× AVIF’s time at medium quality — with Safari the slowest of the browsers. The gap narrows at very high quality settings. Decode time matters for scroll performance and lightboxes, not just file size, and the table above measures it on the artifact the encoder just produced.

Is WebP still worth using?

Yes, as the compatibility layer. AVIF beats it on size at like quality, but WebP still beats JPEG by 25–35%, is decoded by effectively every browser since ~2020 including old Safari and Android, and encodes fast enough to run interactively. A common 2026 setup is AVIF first, WebP (not JPEG) as the <picture> fallback — you can measure both rows above and see exactly what the safety net costs you.

Can I convert between AVIF, JPEG XL, and WebP here?

You can download every artifact the comparison produces — drop a PNG, pick the winning format, press the download button on its row; the file is the exact encoded artifact you were shown. For full conversion workflows, this site has an in-browser JXL to JPG converter, HEIC and RAW batch converters, and archive-to-archive conversion — all with the same no-upload guarantee.

Is my image really not uploaded anywhere?

Really. The encoders run as WebAssembly in this tab; the only network requests are the one-time engine files (~0.3–3.4 MB each, from this site’s own domain, cached afterwards) and the page itself. Open DevTools and watch: no request after the engine download contains your image. Load the page, go offline, and the comparison still runs.

Drop an image herePNG · JPEG · WebP · GIF · BMP · AVIF — or JPEG XL on browsers that decode it. It never leaves this tab.

How the comparison works

The pipeline is deliberately boring so the numbers stay trustworthy: your browser decodes the dropped file to raw pixels once; every format then encodes those same pixels; each encoded artifact is decoded back and compared byte-for-byte with the source. Three quality stops (50 / 75 / 90) and three effort levels (fast / balanced / thorough) map to each encoder’s native knobs — rav1e’s speed, libjxl’s effort, libwebp’s method — so you can see how much of the “format war” is actually just settings.

The engines: AVIF via rav1e (@jsquash/avif 2.1.1), JPEG XL via the reference libjxl (@jsquash/jxl 1.3.0), WebP via libwebp (@jsquash/webp 1.5.0) — the Squoosh-lineage WebAssembly builds, self-hosted. JPEG and PNG rows are your browser’s own canvas encoders and cost no download at all. AVIF runs deliberately at 4:4:4 chroma (no subsampling): the October 2026 benchmark found 4:2:0 rarely buys meaningful bytes and blocks the high-quality end of the range — so if you have been shipping 4:2:0 AVIF out of habit, compare against what 4:4:4 costs you here.

Size — the encoded artifact, with the percentage delta against your source file’s bytes.
Encode — wall-clock time of the encode call itself, engine download excluded. Your CPU, not a data center’s.
Decode — how long this browser takes to decode the artifact back to pixels (a real <img> would pay this). For JPEG XL on browsers without native JXL, the row says so and times the WebAssembly decode instead — a wasm number is not comparable to a native one, and the table does not pretend otherwise.
Difference — PSNR against your source pixels: a strict mathematical measure, not a perceptual one. Pixel-identical means the lossless round-trip was verified on your machine, byte for byte.

What the published benchmarks say

For the corpus-scale landscape, Jake Archibald’s October 2026 benchmark is the current reference work — a large photo corpus, two JPEG XL encoders against AVIF, scored with SSIMULACRA2 and ColorVideoVDP (which, usefully, often disagreed with each other — a honesty signal, not a weakness). Its headline findings, so you know what to expect before you drop a file:

Lossy photos: AVIF usually wins. The best JPEG XL outputs came out 6–25% larger than AVIF at comparable quality (15–25% at default effort, 6–20% at maximum). Outliers exist — one detailed photo had JPEG XL *beat* AVIF — which is precisely why testing your own image matters.
Screenshots and illustrations: AVIF wins big. JPEG XL ran 20–90% larger depending on effort — flat-color synthetic content is AV1 territory.
Lossless: JPEG XL is the clear winner. For lossless photos, WebP came out 9–17% larger than JXL and lossless AVIF 30–120% larger. Drop a PNG above, switch the mode toggle to lossless, and watch this ordering reproduce (or not) on your file.
JPEG recompression: a JPEG XL exclusive. JXL can losslessly re-wrap an existing JPEG 9–20% smaller and hand back the exact original bytes on decode — AVIF and WebP have nothing comparable.
Transparency: AVIF wins. The JXL encoders default to lossless alpha, making transparent images 2–3× AVIF’s size.
Decoding: AVIF is faster. JPEG XL took 2–3× longer to decode at medium quality (the gap narrows at very high quality), with Safari the slowest at JXL. Decode cost matters at scroll speed, not just bytes.
His bottom line: default to AVIF at 4:4:4 with the highest effort you can be bothered with; try JPEG XL when an AVIF comes out unusually large. Both encoders are improving fast enough that any conclusion older than your last browser update is stale.

Browser support, October 2026

The support picture is why this debate got loud recently. JPEG XL just became a mainstream format: Chrome 155 (desktop, released October 6, 2026) ships native JPEG XL decoding after the format’s five-year ship-remove-reship saga; Safari has decoded it since version 17 (2023); Firefox is expected to land it in version 157 around November 2026. AVIF finished that climb years ago — Chrome 85 (2020), Firefox 93 (2021), Safari 16.4 (2023) — and WebP has been universal since roughly 2020.

The practical reading, if you ship images today: AVIF is the safe modern default (small, universally decodable, hardware-decoded on recent phones), JPEG XL is the capability pick (lossless, JPEG recompression, progressive rendering, better at very high quality), and WebP is the conservative middle — a little larger than AVIF, supported everywhere including old Safari and old Android. A <picture> element with an AVIF source and a WebP or JPEG fallback still covers essentially every browser that has ever visited a website.

Reading the numbers honestly

PSNR is not perception. It treats every pixel equally and knows nothing about masking, texture, or where your eye actually goes; two encoders can tie on PSNR while one looks visibly better. The perceptual metrics used in published work (SSIMULACRA2, ColorVideoVDP) exist precisely because PSNR falls down here — and they routinely disagree *with each other*. That is why this page gives you the hold-to-compare preview: for the formats-actually-look-fine-at-q75 question, your eyes on your image are the metric that matters; PSNR is the tripwire that tells you when to look closely.

The times are honest but local: encode milliseconds say more about your CPU than about a phone or a data center, and the first run of each engine includes a one-time ~0.3–3.4 MB download from this domain (cached afterwards — go offline and compare again). One deliberate scope limit: the JPEG XL engine here is the reference libjxl; the newer jixel encoder that sometimes beats it is not available as a stable WebAssembly build yet, so JXL’s row here is libjxl’s best case, not the format’s theoretical ceiling.

Which format should you ship?

A decision procedure you can run with the tool above:

Photographic web delivery: encode your actual hero image above at q75, balanced. If AVIF is smallest and looks fine held against the original — and it usually will — ship AVIF (4:4:4), with WebP or JPEG in the <picture> fallback.
Screenshots, UI captures, flat illustration: check the same run — the AVIF-vs-JXL gap on synthetic content is the largest in the whole field; AVIF or even well-tuned WebP usually wins by a mile.
Archival or master copies: switch the toggle to lossless. JPEG XL typically comes out smallest of the true-lossless options, and if your source is a JPEG, JXL’s lossless-JPEG recompression (elsewhere on this site: open a .jxl) is the only way to shrink it without touching a single bit.
Very high quality targets (q90+): worth re-checking rather than assuming — this is the corner where JPEG XL closes the size gap on AVIF and sometimes passes it, on large images especially.
Maximum compatibility (email clients, old apps): the JPEG row exists so the modern formats have to *beat* something real, not a strawman — if the delta is small for your image, compatibility may simply be worth more than the bytes.

Honest limits

Real capability, real boundaries — stated up front.

Nothing leaves the tab. Engines are fetched once from this site’s own domain and cached; after that the comparison works offline.
Camera RAW, HEIC, and TIFF inputs are refused — not because they cannot be decoded here (they can, in the RAW, HEIC, and TIFF viewers) but because those pipelines re-encode through JPEG on the way in, and a lossy pre-step would quietly taint every number. Export to PNG first.
Animated images are out of scope — the benchmark encodes the first frame. For animation, published measurements agree: use a muted autoplay <video>, not an animated image format.
HDR (10/12-bit, PQ/HLG) is not compared — the source pipeline is 8-bit RGBA, and honestly comparing HDR needs perceptual metrics this page deliberately does not fake.
Size caps keep the tab alive: 25 MB per input, 30 megapixels decoded. At thorough effort on large photos, AVIF’s encode can take tens of seconds — that is real and cancellable, not a bug.
EXIF does not survive. The artifacts you download are pixel encodes; shooting metadata and GPS stay with your original file.

Credits

The engines are rav1e (AVIF), libjxl (JPEG XL), and libwebp — packaged as WebAssembly by jSquash from the Squoosh lineage, served from this site’s own domain as standalone cacheable files. The corpus-scale landscape cited throughout is Jake Archibald’s “JPEG XL vs AVIF for web use-cases” (October 2026), the benchmark that finally replaced forum folklore with measurements. This page adds the part a published corpus cannot: your image, your machine, your answer.