Pick the right image format in 2026: WebP, AVIF, JPEG XL, PNG, JPEG
A practical 2026 decision tree for choosing between WebP, AVIF, JPEG XL, PNG, and JPEG, including the cases where the obviously-best format is the wrong call.
The modern image-format question used to be easy. JPEG for photos, PNG for anything with transparency, GIF for the few things still making sense as GIFs. By 2026 there are five real contenders, two of them deeply opinionated about which browsers they care about, and two of them slow enough that the savings sometimes do not pay off the wait.
This is the framing the rest of the article rides on: every format is correct for some job and wrong for the others. There is no universal "use this." There is a short list of questions, and the answers point you at one format.
图像压缩器
批量压缩为 WebP、AVIF、JXL，支持高级参数调节
What actually changed since the last time you cared
Three things, all in the last 18 months.
AVIF is now safe to ship as the primary format. Caniuse puts it around 93–94% global support, with Chrome on board since version 85, Firefox enabled by default with hardware acceleration, Safari 16+, and Edge tagging along on the Chromium side. The 6–7% gap is mostly older iOS devices stuck on iOS 15, and you handle that with a <picture> element fallback to WebP. Nothing exotic.
JPEG XL is the more interesting story. Apple shipped native decoding in Safari 17 in September 2023 across macOS, iOS, iPadOS, watchOS, and visionOS. For three years Chromium refused to follow. Then in early 2026 the Chromium team reversed course: Chrome 145 ships a JXL decoder again, but it sits behind chrome://flags/#enable-jxl-image-format and is off by default. Effective real-world support sits around 12%, almost entirely Safari users. That number will move only when Chrome flips the flag.
WebP keeps doing what WebP does. About 97% global coverage, supported by everything that matters, and roughly 25–35% smaller than JPEG at equivalent quality.
So the practical landscape is: WebP works everywhere, AVIF works almost everywhere with a small fallback, JPEG XL works for Safari users and curious flag-flippers. JPEG and PNG are not going away because the universe of devices and software that needs to decode them is too large to ever fully migrate off.
The encode-time tax nobody factors in
If you have been quietly assuming the best-compressing format is also the best choice, here is the tax: AVIF encodes 5–20× slower than WebP, and JPEG XL is in the same neighborhood depending on the effort setting. A high-resolution photo at AVIF quality 60 can take 30–60 seconds to encode in a browser. WebP at the same visual fidelity finishes in a few seconds. JPEG finishes in a blink.
That is fine when you are encoding once and serving the file forever. It is not fine when you are batching 200 wedding photos, or when you are iterating on a quality setting, or when you are running on a phone. The encode tax is a real cost and the right format depends partly on whether you are paying it once or a thousand times.
A decision tree, for real this time
The tree has five branches. Pick the one that matches your job.
Branch one, web delivery, photos, you control the markup. Serve AVIF as the primary, WebP as the fallback inside a <picture> element. Quality 60 AVIF is roughly equivalent to JPEG quality 80+, so you can be aggressive. Skip JPEG XL: not worth the partial support story for most production sites.
Branch two, web delivery, photos, you do not control the markup. Use WebP everywhere and stop. CMSes that auto-rewrite image URLs, marketing platforms, third-party widgets, embedded comment systems. None of these consistently emit <picture> correctly, and AVIF without a fallback breaks for the users still on older devices. WebP at quality 80 covers 97% of browsers and stays well behind JPEG in size.
Branch three, UI assets, icons, screenshots, technical diagrams. Anything where a single resampled pixel would be visible, or anything with sharp edges and text. Stay on PNG, then run it through OxiPNG to strip the slack. Lossless rules apply because lossy compression is what makes that red-on-white pixel turn into a brown-pink halo.
Branch four, transparency that needs to scale. WebP has a lossless mode that handles alpha cleanly and produces files smaller than PNG for most assets that have any color complexity. Use it. AVIF technically supports alpha too, but the encoder behavior around alpha is more variable and the savings versus WebP are smaller for graphics than for photos.
Branch five, archival, near-lossless, you have Apple users to please. JPEG XL becomes interesting here. The compression is excellent, the quality holds up, Safari decodes it natively, and your archive does not need everyone on Earth to be able to open it. For everything else, JPEG XL is a 2027 problem.
Where each format shows its weakness
Real talk on the failure modes, because every recommendation above has one.
JPEG: chroma subsampling at 4:2:0, which is the default below quality 90 in most encoders, turns red text on white backgrounds into a smeared mess. If your image has UI elements, screenshots, or sharp colored edges, either encode at quality 90+ to get 4:4:4 chroma, or pick PNG. The mozjpeg encoder gives you trellis multipass and Huffman optimization that recover 5–15% of size at the same visual quality, so for actual photos there is no reason to use the standard encoder anymore.
PNG: large for what it is. A 2 MB UI screenshot is normal. OxiPNG can usually shave 20–60% off without touching a pixel, but it still cannot compete with WebP lossless or AVIF for any image that has more than a few colors and is not load-bearing on pixel perfection.
WebP: the lossless mode is good but slower than people expect. Color management around the alpha channel is fine but not flawless. If you are color-grading for print, do not round-trip through WebP.
AVIF: encode time, as discussed. The encoder also has a quirky relationship with very low quality settings. Going below quality 30 produces obvious artifacts that JPEG would not. And the alpha channel handling is encoder-dependent.
JPEG XL: support, full stop. Until Chrome flips the flag default-on, this is an interesting format with limited real-world reach.
What this means for the actual workflow
Here is the boring practical answer: for almost every site shipping in 2026, the answer is "WebP everywhere, AVIF where you control the markup, OxiPNG for UI assets, JPEG XL when you want to be early." Holding aside the edge cases, that combination covers the user base, hits the file-size budget, and does not punish your build pipeline.
The image-compressor tool runs all five encoders client-side via WebAssembly, so you can compare formats on the same source image without three separate uploads. Drop a hero photo in, encode it five ways, look at the size and the visual difference side by side, and pick. That comparison is faster than reading another benchmark.
The 2027 watch list
A few things to keep an eye on. Chrome's default JPEG XL flag is the obvious one. If it flips, JXL becomes a real production option overnight and "AVIF or JXL?" stops being theoretical. AVIF encoder performance is improving each year as libavif gets faster; the encode tax may shrink to the point where the choice between WebP and AVIF becomes purely about the fallback story. And HEIC, the format that iPhones save photos in, may become more widely supported on the web side, which would close the round-trip loss most iPhone users currently take when sharing to anything that is not Apple Photos.
For now, the boring answer wins. WebP everywhere. AVIF when it is safe. PNG when pixels matter. The decision tree above is the one you actually want pinned to your monitor.
Image Compressor · Z.Tools
Batch compress to WebP, AVIF, JXL with advanced controls
