WebP vs AVIF vs JPEG: format selection in 2026

Image codec choice depends on three practical factors: client compatibility, encoding speed, and visual efficiency across targeted content types.

All three formats maintain legitimate use cases, and the benchmark that circulates with each new format rarely answers the question actually in front of you: what should this image be saved as, today, for the place it is going? The mechanical differences below answer it in about ten seconds.

Specification summary

The rule the rest of this post explains: WebP for the web, JPEG when something outside the browser has to open the file, AVIF when one image is large and prominent enough that another 20% of payload justifies a slow encode.

JPEG: universal compatibility and rapid encoding

JPEG remains thirty years old and ubiquitous. Offline image viewers, legacy office suites, accounting software, and government upload forms process baseline JPEG without compatibility issues. It wins on the axis no benchmark measures: an image that has to leave the web and enter someone else's workflow arrives without generating an email.

JPEG also encodes quickly. At roughly 40 milliseconds per photograph, a batch of one hundred high-resolution images finishes in seconds, which is what makes JPEG practical for desktop utilities and high-throughput ingestion pipelines.

JPEG fails in three areas:

• No alpha support: JPEG cannot encode transparency. Transparent regions flatten onto a solid background colour.
• Gradient posterization: 8-bit discrete cosine transforms introduce stepped banding across subtle skies and shadow gradients.
• Ringing artefacts around sharp edges: Text glyphs and UI borders pick up mosquito noise from high-frequency quantization.

Those three failure modes double as the specification for when to reach for something else: transparency, wide smooth gradients, and hard-edged screenshots or diagrams.

WebP: the unified web default

WebP consolidates photographic and vector compression inside a single container specification:

• Lossy mode: Replaces JPEG for continuous-tone photography with 25–35% lower payload sizes at matched quality.
• Lossless mode with alpha: Replaces PNG for UI icons, graphics, and screenshots with 20–30% lower payload sizes.

The payload reduction matters less than that consolidation. One format covers both jobs, so a mixed folder of photographs, logos, screenshots, and icons converts to WebP as a single operation, and nobody has to maintain a policy about which assets are PNG and which are JPEG.

All major browsers have supported WebP since 2020. Non-browser desktop applications and legacy email clients occasionally reject WebP, which is why JPEG remains useful as a fallback.

Converting an already-compressed JPEG to WebP yields limited bandwidth savings, sometimes none. The original lossy encode already discarded the fine source frequencies that both formats would have discarded, so the second encode is working on what survived. Published comparisons measure against uncompressed masters, which is the fair test but not the one most people are running. For the real number on your own files, run a few through the converter and compare the output sizes directly.

AVIF: maximum compression efficiency

Derived from the AV1 video standard, AVIF delivers higher compression ratios than WebP. Its directional transforms and chroma prediction models maintain clean visual fidelity at low bitrates where JPEG breaks into blocks. A sky that posterizes visibly as a quality-80 JPEG can stay smooth as an AVIF at half the file size.

However, AVIF involves clear engineering trade-offs:

High encoding latency. Depending on encoder CPU effort settings, AVIF can take ten to fifty times longer to compress than JPEG. On a single hero image that cost is invisible. On two hundred catalogue photographs it is the difference between a coffee break and an afternoon, which is a precise description of where AVIF belongs.

Incomplete legacy support. Current versions of Chrome, Safari, Firefox, and Edge decode AVIF, but older OS installations, enterprise webviews, and third-party desktop tools do not. Use AVIF when your CDN or server can negotiate content types via Accept request headers and deliver WebP or JPEG fallbacks. Without a fallback path, incomplete support is a blocker rather than a trade-off.

Container overhead on small assets. AVIF incurs fixed container header overhead. Below 10 KB (favicons, UI badges, avatars), container metadata offsets compression gains, often resulting in larger payloads than WebP or optimized PNG. The advantage grows with image area, which is why AVIF earns its encode time on full-width photography and nothing at all on a 48-pixel avatar.

Format selection framework

Evaluate three criteria in order.

1. External compatibility constraints

If the file leaves your web ecosystem (submitted to email clients, print shops, government portals, or legacy desktop suites), use JPEG (or PNG if alpha transparency is required). This criterion comes first because it is a hard constraint. The two below are optimisations.

2. Alpha transparency requirements

If transparency is required, JPEG is eliminated. Select lossless WebP for line art, typography, and UI graphics. Use lossy WebP with alpha for photographic cutouts to keep payload sizes small.

Worth knowing before you start a batch: removing a background produces an alpha channel, and exporting the result as JPEG silently composites it onto white. That is the most common way people lose the transparency they just generated.

3. Image dimensions and catalogue volume

• Large hero imagery (1200+ pixels wide): Use AVIF when your server supports fallback negotiation. The encoding cost occurs once during deployment, while bandwidth savings apply to every client request.
• Catalogues and high-volume batches: Use WebP. It balances fast encoding with substantial file size reductions, delivering most of AVIF's saving for a fraction of the CPU time.
• Icons and thumbnails (< 10 KB): Use WebP or SVG for vectors. AVIF container overhead provides no advantage at this scale.

Dimension scaling before format encoding

Format choice accounts for roughly 30% of total payload savings; pixel dimensions determine the remaining 70%.

An image displayed at 800 pixels wide stored at 4000 pixels wide carries twenty-five times the pixel data it will ever show, and no codec recovers that. Converting a 3 MB file from JPEG to AVIF might reach 1.5 MB. Downsampling it to its display dimensions reaches roughly 90 KB first, and the format choice then takes it to about 60 KB.

Recommended pipeline order:

1. Downsample to target viewport dimensions, with a 2× allowance for high-density screens.
2. Select format based on the criteria above.
3. Compress at quality 75–85 and inspect high-contrast edges. That band is the knee of the curve for every lossy codec: far smaller than quality 95, and visually indistinguishable in most photographs.

Running compression before resizing degrades visual fidelity twice while increasing output size.

Technical misconceptions

"Lossless yields higher fidelity than quality 100." Lossless indicates zero generational data loss relative to the input file. Converting a compressed JPEG into PNG or lossless WebP preserves previous compression artefacts verbatim, in a much larger file. Lossless is correct for masters, screenshots, and line art. It is not a quality upgrade.

"Re-encoding at high quality restores detail." Quantization discards frequencies permanently. Re-saving a degraded image at quality 100 bloats the container without restoring lost source pixels. Detail reconstruction requires generative neural upscaling rather than codec re-encoding, and the difference matters: one infers plausible detail, the other recovers none.

"WebP is strictly lossy." WebP supports both independent lossy and lossless algorithms, and so does AVIF. The format name never reveals which mode produced a given file, which is why "convert it to WebP" is an incomplete instruction for an automated pipeline.

"The highest quality setting is the safe default." Quality 100 in a lossy codec is not lossless. It is the most expensive lossy setting available, spending its bitrate encoding quantization noise at full fidelity. Anything that genuinely needs lossless should ask for lossless.

For most web work, the answer is WebP at quality 80, resized to its display dimensions. Reach for AVIF when one image is large and prominent enough that another 30% of payload is worth the encode, and for JPEG the moment the file has to open somewhere you do not control. OpusImg's format converter and compressor execute WebAssembly codecs directly in client browsers, so those comparisons run on your own photographs without transmitting them anywhere.