LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Image Codecs Compared

14 min read Photography & Imaging Engineering
image-codecsavifjpeg-xlwebpheicphotography-imaging
Contents

The question “which image codec is best” has no answer, because the modern formats were built for different battles and the one that wins a benchmark frequently loses the war that actually matters: adoption. AVIF can beat JPEG by half the file size and still be the wrong choice for a photographer’s archive; JPEG XL can be the most technically elegant format in the field and still be undeliverable to most of the web because one browser vendor pulled it. HEIC is on a billion phones and almost no web pages. The honest comparison is not a single leaderboard but a matrix of three independent axes — compression efficiency, feature support, and licensing — where the third axis quietly overrules the first two. A format that compresses 20 percent better than its rival but carries a patent pool the browser makers refuse to license is, for web purposes, the worse format. That is the uncomfortable lesson of the last decade of image coding, and it is exactly the same dynamic that played out in audio codecs, where the royalty-free option won distribution even when it was not the cleanest compressor.

This post measures the four contenders against all three axes, with real encoder commands and an honest account of where each one earns its place in a production pipeline.

What “better” even means

Comparing image codecs on one number is how marketing decks lie. There are at least five axes that matter, and they trade against each other:

  • Compression efficiency — bits per pixel (bpp) needed to reach a target perceptual quality. This is the headline number, and it is the most over-quoted.
  • Encode and decode speed — AVIF’s best quality comes from slow encoders; JPEG decodes in microseconds on hardware that has existed for twenty years. A format that takes 4 seconds per image to encode reshapes your build pipeline and your CDN bill.
  • Feature support — alpha transparency, HDR (10/12-bit), wide color gamut, animation, progressive decoding, and lossless mode. Not every format does all of these, and the gaps decide use cases.
  • Fidelity behavior — how a codec fails at low bitrate. Some smear, some block, some ring. A codec that is efficient on average but ugly on skin tones or text is unusable for the content where it would be ugly.
  • Licensing — royalty-free versus patent-pool-encumbered. This decides whether browsers and open-source tools will ship a decoder at all.

Perceptual quality itself must be measured carefully. PSNR and even SSIM correlate poorly with what eyes see at the qualities people actually ship. Serious codec comparison now uses SSIMULACRA2 and butteraugli, metrics tuned to human vision, and the rankings shift depending on whether you are testing “visually lossless” (high bpp) or “good enough thumbnail” (low bpp). A format can win one regime and lose the other, which is why a single “AVIF is 50% smaller” claim should always trigger the question: at what quality, on what content, measured how?

The four contenders

All four modern formats except one share a surprising lineage: they are still-image profiles of video codecs, because an I-frame (a fully self-contained video frame) is exactly an still image, and video codecs have absorbed thirty years of compression research that JPEG never received.

  • WebP (Google, 2010) is a VP8 intra frame in a RIFF container. It was the first widely shipped “better JPEG,” supports lossy and lossless modes plus alpha and animation, but is locked to 8-bit and 4:2:0 chroma in its lossy mode — no HDR, no wide gamut. Royalty-free under a BSD-style license.
  • HEIC (Apple’s adoption of HEIF, 2017) is an HEVC intra frame in the ISO HEIF container. It supports 10-bit HDR, alpha, depth maps, and image sequences (this is how Live Photos and iPhone bursts are stored). Technically strong, but it inherits HEVC’s notoriously fragmented patent licensing.
  • AVIF (AOMedia, 2019) is an AV1 intra frame in the HEIF container. It carries everything HEIC does — 10/12-bit, HDR, wide gamut, alpha, film-grain synthesis — and adds the decisive feature of being royalty-free, because AV1 was explicitly designed by the Alliance for Open Media to avoid patent pools.
  • JPEG XL (ISO/IEC 18181, 2021) is the outlier: a clean-sheet design from the JPEG committee itself, not a video-codec derivative. It has two internal modes — VarDCT for photographic lossy (a much-improved descendant of JPEG’s DCT) and Modular for lossless and non-photographic content — plus two features nobody else has: true progressive decoding and reversible JPEG transcoding that re-compresses an existing JPEG ~20% smaller and can reconstruct the exact original bytes. Royalty-free, with a BSD-licensed reference encoder.

The technology under the hood

What makes all of these beat 1992’s JPEG is not magic; it is the accumulation of techniques JPEG predates. JPEG cuts the image into fixed 8×8 blocks, applies a discrete cosine transform, quantizes, and entropy-codes with Huffman. The modern codecs improve on every one of those steps.

Variable block sizes. Instead of fixed 8×8, AV1/HEVC partition adaptively — large blocks across smooth sky, tiny blocks across detailed foliage — spending bits where the image is complex and almost none where it is flat.

Intra prediction. Before transforming a block, the codec predicts it from already-decoded neighboring pixels using directional modes (45 of them in AV1), then codes only the residual. JPEG has nothing like this; it codes every block from scratch.

Better transforms and entropy coding. AV1 uses multiple transform types (DCT, ADST, identity) chosen per block, and arithmetic-style entropy coding that beats Huffman by a few percent on its own. JPEG XL’s VarDCT uses variable DCT sizes (from 2×2 up to 256×256) plus an adaptive context model.

Chroma-from-luma. AVIF and JPEG XL can predict the color channels from the luma channel, exploiting the correlation JPEG throws away with naive 4:2:0 subsampling.

JPEG XL’s most pragmatic trick deserves its own mention because it sidesteps the entire adoption problem for archives: its lossless JPEG recompression. Run cjxl photo.jpg photo.jxl and you get a file about 20% smaller that decodes back to a byte-identical JPEG. For a photo library of millions of legacy JPEGs, that is a fifth of the storage bill recovered with zero generational loss — a property none of the video-derived codecs offer, since transcoding a JPEG through them is lossy.

Compression, honestly

Here is the part everyone wants as a single number, presented with the caveats that make it true. The figures below are representative of careful SSIMULACRA2-aligned testing on photographic content at web-delivery quality; they are directional, not gospel, and they invert at the extremes.

Codec Typical size vs JPEG (same quality) Best regime Weakness
JPEG (baseline) 1.00× (reference) Universal decode, instant Old, no HDR/alpha
WebP (lossy) ~0.70–0.75× Drop-in JPEG replacement 8-bit only, marginal gains
HEIC (HEVC) ~0.50–0.55× Phone capture, HDR Patent pools, no web support
AVIF (AV1) ~0.45–0.55× Low bitrate, smooth/synthetic, HDR Slow encode, smears fine texture
JPEG XL (VarDCT) ~0.45–0.55× High fidelity, lossless, JPEG transcode Fragmented browser support

The crossover is the real story. At low bitrate — thumbnails, aggressive web compression — AVIF wins, because AV1’s prediction and chroma handling degrade gracefully into a soft, blur-like loss that the eye forgives. At high fidelity — “visually lossless,” the quality a photographer or print shop wants — JPEG XL pulls ahead, preserving fine grain and texture where AVIF starts to smear detail into plasticky smoothness. AVIF’s weakness is exactly that smoothing: it can erase film grain, skin texture, and fine fabric, which looks fine on a chart and wrong on a portrait. JPEG XL also encodes substantially faster than a high-effort AVIF encoder and decodes progressively, so a JXL can paint a low-res preview from the first bytes received.

WebP, a decade on, is the least impressive: its ~25–30% win over JPEG is real but modest, and AVIF and JXL roughly double that. WebP’s continued relevance is entirely about its universal browser support, not its compression.

The patent and licensing reality

This is the axis that overrules the others, and it is why HEIC is everywhere on phones and nowhere on the web.

HEVC — the codec inside HEIC — is licensed through multiple, competing, partially-overlapping patent pools (Access Advance, MPEG LA’s successor arrangements, Velos Media) plus licensors who sit outside any pool. No one can tell you with certainty what it costs to ship an HEVC decoder, because there is no single counter to pay. Browser vendors, who ship to billions of users and cannot absorb open-ended royalty exposure, simply declined. That single fact — licensing fragmentation, not technical merit — is why you will never get an image/heic straight onto a web page in Chrome or Firefox.

AV1, and therefore AVIF, was engineered specifically to avoid this. The Alliance for Open Media — Google, Apple, Microsoft, Amazon, Netflix, Mozilla, Intel and others — built AV1 with a royalty-free patent cross-license among members and a defensive patent commitment. That is why every one of those companies could ship an AVIF decoder without a licensing negotiation, and why AVIF achieved full browser support within a few years.

JPEG XL is likewise royalty-free, with the contributing companies (Google, Cloudinary) committing their patents and a BSD-licensed reference implementation. On paper its licensing is as clean as AVIF’s.

Codec Licensing Royalty-free? Practical consequence
JPEG Expired patents Yes Universal, no constraints
WebP BSD (VP8) Yes Shipped everywhere
HEIC HEVC patent pools No Phone-native, web-blocked
AVIF AOMedia commitment Yes Full browser support
JPEG XL Royalty-free, BSD ref Yes Clean, but adoption stalled anyway

JPEG XL is the proof that royalty-free is necessary but not sufficient. It cleared the licensing bar and still stalled, for a reason that has nothing to do with patents and everything to do with one rendering engine.

Browser and editor support, honestly

Here the formats split into “deliverable” and “not.”

WebP is universally supported — every current browser, every major editor. It is the safe default and the universal fallback above JPEG.

AVIF reached full coverage across Chrome (2020), Firefox (2021), and Safari (2022), and is now a first-class web format. Editor support landed more slowly but is real: native in modern Photoshop, GIMP, Affinity, and the sharp/libavif toolchains every build pipeline uses.

HEIC is the inverse: native to iOS and many Android cameras, supported in Apple’s and Microsoft’s OS image viewers, and essentially absent from browsers. It is a capture and storage format, not a delivery format.

JPEG XL is the cautionary tale. Chrome added it behind a flag, then removed it in early 2023, citing insufficient ecosystem interest and a preference not to maintain the C++ decoder’s memory-safety surface. Safari 17 shipped JXL support later that same year. Firefox keeps it behind a nightly flag. The result is a format that is genuinely excellent and genuinely undeliverable to the majority of web traffic, because you cannot rely on it in the dominant engine. The thaw, if it comes, runs through jxl-rs, a memory-safe Rust decoder built specifically to answer Chromium’s stated objection — until that lands and ships by default, JPEG XL on the open web remains a Safari-and-fallback proposition. For non-web uses — photo libraries, archives, internal tools where you control the decoder — none of this matters, and JXL is arguably the best choice available.

WHERE EACH FORMAT EARNS ITS PLACE

  CAPTURE            EDIT / MASTER          DELIVER (web)        ARCHIVE
  -------            -------------          -------------        -------
  HEIC (phone)  -->  RAW / TIFF / PSD  -->  AVIF (primary)  -->  JPEG XL (lossless)
  DNG (camera)       (lossless work)        WebP (fallback)      or original RAW
                                            JPEG (legacy)
       \                                         |                   |
        \_____ HEIC is great here ______________/                    |
                but never reaches the browser                        |
                                                                     |
   JPEG XL transcodes legacy JPEGs ~20% smaller, byte-reversible ----/

In production: what actually saves bandwidth

The codec only saves bandwidth if it actually reaches the user, which on the web means content negotiation: serve AVIF to browsers that accept it, WebP to those that do not, and JPEG to the rest, all from the same <img>. The browser advertises support in its Accept header, and you respond with the best format it named. The standard markup pattern is the <picture> element with typed sources, which the browser resolves top-down to the first type it understands:

1
2
3
4
5

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1600" height="900" loading="lazy">
</picture>

Generating those variants is a few encoder calls. The reference tools, all command-line and scriptable into any build:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# WebP (libwebp): -q quality, -m effort
cwebp -q 80 -m 6 hero.png -o hero.webp

# AVIF (libavif): -s speed 0=slowest/best ... 10=fastest
avifenc --min 20 --max 30 -s 4 hero.png hero.avif

# JPEG XL (libjxl): -q quality, -e effort 1..9
cjxl -q 88 -e 7 hero.png hero.jxl

# Lossless, byte-reversible JPEG -> JXL recompression
cjxl legacy.jpg legacy.jxl          # ~20% smaller, decodes back identical

# One-shot multi-format with ImageMagick / sharp in a build step
magick hero.png -quality 80 hero.webp

Three production realities temper the wins:

  1. Encode cost is not free. A high-effort AVIF encode can be 10–100× slower than a JPEG. At scale you either accept a fast/lower-effort AVIF speed setting, encode asynchronously, or push the work to an image CDN that does it once and caches. The bandwidth saving is real; the CPU to realize it is a line item — the kind of cost-versus-latency trade explored in web performance engineering.
  2. Negotiation belongs at the edge. Serving the right variant per request multiplies your cache keys; doing it in a CDN that varies on Accept and stores each representation is how you avoid origin load and a cache-hit-ratio collapse, as covered in a modern CDN, honestly.
  3. HDR and color need handling. AVIF and JPEG XL can carry 10-bit HDR and wide-gamut data, but only if your pipeline tags the color space correctly end to end; mishandle the ICC profile or transfer function and “wider gamut” becomes “wrong colors,” the failure mode detailed in color management across cameras, screens, and prints.

For most sites, the honest, boring answer is: ship AVIF with a WebP and JPEG fallback via <picture>, let an image CDN do the encoding and Accept negotiation, and you will cut image bytes 40–50% with markup you write once. Reserve JPEG XL for where you control the decoder — archives, internal tools, and the lossless re-compression of legacy JPEG libraries, which is its single most valuable trick.

Verdict

There is no single best image codec, and anyone who quotes one compression number is selling something. The field sorts cleanly by job: AVIF is the web-delivery winner, royalty-free, universally supported, and excellent at the low-to-medium bitrates where web images live, at the cost of slow encoding and a tendency to smooth away fine texture. WebP is the safe fallback — modest gains, but it runs everywhere. HEIC is the phone’s native capture format, technically capable but permanently walled off from the browser by HEVC’s tangled patent pools, which is the whole reason AV1 and AVIF exist. JPEG XL is the most elegant design in the group and the best choice anywhere you control the decoder — superior at high fidelity, faster to encode, genuinely progressive, and uniquely able to losslessly shrink the world’s existing JPEGs — yet it remains undeliverable on the open web because Chrome dropped it, with its return gated on the memory-safe jxl-rs decoder rather than on any technical shortfall.

The meta-lesson is the one the patent axis keeps teaching: compression efficiency proposes, but licensing and browser support dispose. The codec that reaches the user beats the codec that benchmarks best, every time. So serve AVIF with a WebP-then-JPEG fallback for the web, keep HEIC as the capture container it is good at, and reach for JPEG XL in the archive and the photo library where its lossless transcoding pays a storage dividend no rival can match. Match the format to the battle, measure quality with SSIMULACRA2 rather than PSNR, and never trust a single-number comparison again.

Sources

Comments