Login

r/jpegxl

Can JPEG XL still get a sizeable compression boost?
▲ 30 r/jpegxl

Can JPEG XL still get a sizeable compression boost?

I've gotten the impression from some comments on the sub that since AVIF's encoder update earlier this year that it wins at higher compression levels in lossy images.

Is this the case and if so could a future update to JPEG XL's encoder bring it up to parity or beyond?

u/caspy7 — 22 hours ago
▲ 22 r/jpegxl

Compressing images for the web: in 2026, who wins between AVIF and JPEG XL (same quality)?

I dug up some old posts, but there doesn't seem to be a clear winner.

That said, I gotta admit AVIF is pretty impressive with all the settings (and forks) out there, it really feels like you can squeeze more out of it.

reddit.com
u/Wise_Stick9613 — 8 days ago
▲ 0 r/jpegxl+1 crossposts

JPEG-XL vs AVIF

I've been spending a lot of time researching and writing about image compression. I'd love to hear your thoughts on a recent post! You can find the link below, along with the full archive for this topic:

TL;DR: JPEG-XL vs. AVIF

  • AVIF is the overall winner for web developers. Its aggressive compression algorithms and widespread browser support make it the undisputed champion for bandwidth savings.
  • However, JPEG-XL remains an incredibly powerful format with distinct advantages for professional photography, lossless archival, and environments where retaining exact film grain and texture is critical.

https://www.coderevere.com/jpegxl-vs-avif/

https://www.coderevere.com/categories/image-compression/

reddit.com
u/billu51 — 12 days ago
▲ 11 r/jpegxl+6 crossposts

AVIF vs WebP in 2026: which should you actually ship? (a practical decision guide)

This comes up constantly, so here's a no-hype take based on shipping both.

The short version

  • WebP is the safe default. Universal browser support now, fast to encode, smaller than JPEG/PNG, and every CDN and framework handles it. You will basically never regret WebP.
  • AVIF usually wins on size — about 20–30% smaller than WebP, and ~50% smaller than JPEG, at comparable quality. (Ctrl.blog's matched-DSSIM test puts AVIF's median saving over JPEG at 50.3% vs WebP's 31.5%.) Strongest on photos and gradients. The costs are slower encoding and the occasional decode quirk on older devices.

When AVIF is worth it

  • Large hero images and photo-heavy pages where bytes directly hurt LCP.
  • You can serve with a <picture> fallback to WebP/JPEG, so older clients still get something. (Check current support at caniuse.com/avif before assuming.)
  • You're not encoding thousands of images on a tight time budget — AVIF encode is slow.

When to just use WebP

  • Build/encode time matters (CI, on-the-fly resizing).
  • Simple graphics, UI sprites, flat-color PNG-style images — the AVIF win shrinks here.
  • You don't control the serving stack well enough to do proper fallbacks.

The honest nuance most comparisons skip

Quality settings aren't comparable across encoders. AVIF "quality 50" ≠ WebP "quality 50". Compare at matched perceptual quality (eyeball it, or use SSIM/butteraugli), not matched quality numbers, or you'll get misleading size deltas.

My rule of thumb: WebP everywhere by default; AVIF with a WebP fallback for the big images where the byte savings actually move a metric.

What's everyone else doing — full AVIF with fallbacks, WebP-only, or still serving JPEG? And has anyone measured a real LCP improvement from the WebP→AVIF switch?

Sources: Ctrl.blog (AVIF vs WebP at equal DSSIM), web.dev AVIF guide, caniuse.com for current support — roughly 97% WebP and 94% AVIF globally in 2026.

u/Intelligent_Two_4288 — 12 days ago