WebP vs AVIF vs JPEG: quale formato immagine scegliere nel 2026?

TL;DR. AVIF è il 20–30% più piccolo di WebP e il 30–50% più piccolo di JPEG. WebP è circa il 25–35% più piccolo di JPEG. AVIF codifica 5–20× più lentamente di WebP, mentre WebP è il più rapido in decodifica fra i tre. Il workflow vincente nel 2026: servi prima AVIF, ripiega su WebP, mantieni JPEG come rete di sicurezza universale e lascia che sia il browser a scegliere tramite l’elemento <picture>.

Questa risposta basta alla maggior parte dei lettori. La domanda interessante è quando non scegliere AVIF. Saltalo nei budget CI stretti, dove il tempo di codifica conta più dei byte. Tienilo a freno per gli upload utente in tempo reale, perché la codifica AVIF lato browser è ancora frammentaria. Tieni JPEG come primario se devi supportare iOS 16.0–16.3 o vecchie versioni di Edge in circolazione. Ovunque altro, AVIF vince sulla dimensione del file, a patto che il markup <picture> sia corretto e che il tuo CDN invii il MIME type giusto.

Il resto di questa guida è il dettaglio operativo: numeri di supporto 2026, un benchmark su foto reali, un albero decisionale per caso d’uso, pattern <picture> da copiare e incollare, comandi di conversione e le quattro trappole che fanno perdere tempo ai team. Se vuoi solo fare la conversione, il nostro compressore immagini gratuito gestisce JPEG, PNG, WebP e AVIF nel browser senza caricare nulla.

1. Supporto browser 2026: WebP al 97%, AVIF al 93%

Due anni e mezzo dopo che Edge ha rilasciato AVIF, il divario di supporto si è ridotto a pochi punti percentuali del traffico globale. La domanda non è più “è supportato” ma “cosa serviamo all’ultimo 3%?“

1.1 WebP: il default sicuro

WebP è arrivato in Chrome già nel 2012, in Firefox 65 (2019), in Edge 18 (2018) e in Safari 14 (2020). A maggio 2026, caniuse stima il supporto globale al 97% circa. WebP è passato da “alternativa moderna” a “fallback affidabile”. Se servi un solo formato non-JPEG, è WebP.

1.2 AVIF: ora utilizzabile come formato primario

AVIF è arrivato in Chrome 85 (agosto 2020) e Firefox 93 (ottobre 2021). Safari 16.4 lo ha abilitato su macOS e iOS a marzo 2023. Edge è stato il fanalino di coda, aggiungendo il supporto in decodifica solo nella 121 (gennaio 2024). La copertura globale a maggio 2026 è circa il 93–95%.

Un punto critico da segnalare: iOS 16.0–16.3 ha un bug di decodifica AVIF noto che può far crashare Safari su certe immagini. Quelle build sono ancora vive sui dispositivi bloccati dall’MDM aziendale, quindi AVIF senza un fallback funzionante WebP o JPEG è un rischio reale di outage. Trattalo come “primario con assicurazione”, non “primario da solo”.

1.3 Matrice di compatibilità rapida

Formato	Supporto globale (maggio 2026)	Limitazione chiave
JPEG	100%	File più grandi; niente trasparenza; niente HDR
WebP	~97%	Niente HDR né colore a 10 bit
AVIF	~93–95%	Codifica lenta; bug di decodifica iOS 16.0–16.3; richiede Edge 121+

2. Differenze fondamentali: compressione, velocità, funzionalità

2.1 Efficienza di compressione su una foto reale

Un benchmark da sorgente identica. Una fotografia di paesaggio 4000×3000, PNG originale di circa 24 MB, ricodificata a qualità percettiva equivalente:

Codifica	Dimensione	Vs baseline JPEG
JPEG q75 (mozjpeg)	~2,1 MB	0% (baseline)
WebP q75 (libwebp)	~1,4 MB	33% più piccolo
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	52% più piccolo

AVIF q60 qui è visivamente equivalente a JPEG q80 e WebP q75. Le scale di qualità non sono interscambiabili tra codec. Ricodificare “JPEG q75 in AVIF q75” è il classico errore da principianti: finisci con un AVIF sovradimensionato che appare identico al sorgente.

2.2 Velocità di codifica: la tassa 5–20×

AVIF comprime di più perché lavora di più. Usando libavif al cpu-used 4 di default, un’immagine 4000×3000 impiega 5–20× più di libwebp e circa 50× più di mozjpeg. Quel costo si moltiplica nelle build CI, nei cold start di Lambda e nelle pipeline che ricodificano migliaia di asset.

Due valvole di sfogo. cavif --speed 9 (oppure libavif cpu-used 9) si avvicina entro 3× a libwebp al prezzo di file più grandi del 5–8%. E tieni una cache aggressiva: una pipeline di asset content-addressed che salta la ricodifica delle sorgenti immutate riduce un codec lento a un costo una tantum.

2.3 Profondità colore e HDR

JPEG e WebP si fermano a 8 bit sRGB. AVIF gestisce nativamente colore a 10 e 12 bit, Rec. 2020, DCI-P3 e funzioni di trasferimento PQ/HLG. Per le miniature di video HDR, le gallerie fotografiche professionali o le bozze di stampa nel browser, AVIF è oggi l’unica opzione standardizzata.

2.4 Trasparenza e animazione

JPEG non ha né l’una né l’altra. WebP e AVIF supportano entrambi alpha e animazione. Per la sostituzione delle PNG trasparenti in particolare, AVIF codifica l’alpha in modo più compatto: un’illustrazione UI che si riduce del 30–40% come WebP spesso si riduce del 50–70% come AVIF.

3. Albero decisionale: quale formato per quale lavoro

3.1 Siti statici: blog, pagine marketing, documentazione

AVIF primario, WebP fallback, JPEG rete di sicurezza. La codifica avviene una volta sola in CI, quindi la tassa 5–20× si paga in tempo di build, non in tempo utente. Questo è il caso canonico per il pattern <picture> a tre source descritto nella sezione 4.

3.2 Upload utente: avatar, UGC, allegati di form

Comprimi in WebP nel browser, ricodifica in AVIF in modo asincrono sul server. Il canvas.toBlob('image/avif') lato browser oggi funziona solo su Chrome 99+, quindi AVIF non può essere il percorso di upload. WebP comprime velocemente nel browser e fa risparmiare banda sull’upload stesso.

Per un confronto più approfondito tra le librerie client-side (Squoosh, browser-image-compression, Compressor.js) e come si abbinano a Sharp o Imagemin lato server, vedi la guida compressione immagini: browser vs Node.js gemella. La scelta del formato e la sede di elaborazione sono ortogonali; questa guida copre l’asse del formato.

3.3 HDR e fotografia ad alta fedeltà

Solo AVIF. Nessun altro nello stack web aperto supporta oggi colore a 10 o 12 bit. Salta il fallback per gli asset solo HDR, oppure accetta che il fallback JPEG sarà SDR.

3.4 Pubblico con molti browser legacy

JPEG primario, WebP opzionale, niente AVIF. Portali governativi, certi ambienti enterprise dell’Asia orientale e strumenti B2B con lunghe code di dispositivi mostrano talvolta nelle analytics un 5–10% di traffico IE/Edge vecchio. WebP ora è sicuro; AVIF non ancora.

3.5 Distribuzione CDN in tempo reale

libvips o Sharp lato server in streaming WebP, con AVIF generato su un worker in background e servito su cache hit. Non bloccare la risposta sulla codifica AVIF. Cloudflare Polish, Vercel Image Optimization e Cloudinary f_auto automatizzano questo pattern.

4. Il fallback `<picture>` fatto bene

L’elemento <picture> esiste proprio perché il browser possa scegliere la migliore source supportata. Tre livelli, elencando AVIF per primo, ti danno il budget di byte ottimale senza rompere sui client più vecchi.

4.1 La baseline a tre livelli

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Paesaggio di montagna al tramonto"
       loading="lazy" decoding="async" />
</picture>

Tre cose da sottolineare. Il browser percorre gli elementi <source> dall’alto verso il basso e sceglie il primo il cui type comprende; tutto il resto viene ignorato, non scaricato. Il tag <img> è l’elemento effettivamente renderizzato ed eredita gli attributi (alt, sizes, classes) indipendentemente da quale source vinca. E width/height sull’<img> non sono opzionali nel 2026: riservano lo spazio e prevengono il Cumulative Layout Shift.

Per le immagini above-the-fold, sostituisci loading="lazy" con loading="eager" fetchpriority="high". Mettere in lazy-loading l’immagine LCP è uno dei foot-gun più comuni dei Core Web Vitals.

4.2 Responsive più formato: il pattern completo

Quando ti servono anche le risoluzioni responsive, ripeti srcset dentro ogni <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Paesaggio di montagna al tramonto"
       loading="lazy" decoding="async" />
</picture>

Sì, sono nove file generati per immagine. A questa scala, una build step non è negoziabile; la sezione 5.3 mostra cosa collegare.

4.3 Negoziazione `Accept` lato server come alternativa

Se il tuo CDN la supporta, la content negotiation riduce il markup a un singolo tag <img>. Il browser invia Accept: image/avif,image/webp,image/apng,*/* e il CDN risponde con il miglior formato supportato allo stesso URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto e CloudFront con Lambda@Edge implementano tutti questo. Il compromesso: HTML più piccolo e un URL per immagine, ma lock-in del CDN e debug locale più difficile. Una divisione utile è negoziazione CDN per le pagine marketing, <picture> esplicito per la UI di prodotto dove conta il comportamento deterministico.

5. Come convertire le immagini tra formati

5.1 Nel browser, senza upload

Il percorso più rapido per un’operazione una tantum o un piccolo batch è solo browser. Trascina un JPEG nel compressore immagini gratuito, scegli WebP o AVIF come output e il file non lascia mai la tua macchina. L’input AVIF è supportato ovunque; l’output AVIF usa la codifica nativa del browser su Chrome 85+ e ripiega in modo trasparente su WebP nei browser che ancora non sanno codificare AVIF.

5.2 Riga di comando per le pipeline di build

Per una pipeline di produzione vuoi output deterministico e build riproducibili. Questi tre comandi sono reali:

# AVIF: cavif (Rust, installazione facile via cargo o brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (libwebp ufficiale Google)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Entrambi, più resize, via libvips (il più veloce per i batch)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed va da 0 (più lento, più piccolo) a 10 (più veloce, più grande). Il default 4 è il sweet spot per le build notturne; alza a 9 per le anteprime di PR dove la velocità batte i byte.

5.3 Integrazione nella pipeline di build

La maggior parte dei framework per siti statici già wrappa questi encoder. Scegli quello che combacia con il tuo stack:

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programmatico — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Per asset minuscoli (icone sotto i 5 KB circa, avatar inline, intestazioni email) salta del tutto la rete e inlinea come data URI usando la codifica Base64. Questo scambia una richiesta HTTP con qualche byte in più di HTML, di solito una vittoria sotto i ~5 KB.

Se stai scegliendo tra librerie di compressione client-side e lato Node (Sharp vs Squoosh vs browser-image-compression), la guida compressione immagini: browser vs Node.js approfondisce benchmark e compromessi.

6. Trappole e malintesi

6.1 “AVIF vince sempre”: non per screenshot e line art

I punti di forza di AVIF sono le fotografie a tono continuo. Su screenshot con testo nitido, catture di UI e pixel art, WebP produce spesso file più piccoli a parità di qualità. Il deblocking di AVIF può introdurre un sottile banding nelle aree a colore piatto. Esegui le conversioni in entrambi i modi e scegli il vincitore per classe di asset.

6.2 “Il WebP lossless sostituisce perfettamente i PNG trasparenti”: quasi, non identico

Il WebP lossless è davvero più piccolo di PNG, in genere del 26% circa. La fregatura: “lossless” si applica all’immagine compressa, ma l’encoder può comunque alterare l’arrotondamento del canale alpha nelle aree ad alto gradiente. Per la riproduzione esatta al pixel (immagini medicali, asset d’archivio, qualunque cosa legalmente tenuta a corrispondere alla sorgente), tieni PNG. Per tutto il resto, il WebP lossless è un guadagno netto.

6.3 “Basta caricare i file .avif”: il tuo CDN potrebbe non sapere cosa siano

Le configurazioni più vecchie di nginx e Apache precedono AVIF. Se /etc/nginx/mime.types non elenca image/avif avif;, nginx serve AVIF come application/octet-stream. Il browser vede il Content-Type sbagliato, si rifiuta di renderizzare l’immagine e ripiega silenziosamente su JPEG, vanificando l’intera ottimizzazione. Fai un curl all’URL dell’asset dopo il deploy e controlla l’header Content-Type. Cinque secondi di paranoia ti risparmiano una settimana di “perché AVIF è rotto in produzione”.

6.4 Il crash AVIF di iOS 16.0–16.3

Alcuni file AVIF innescano un crash di decodifica di Safari su iOS 16.0–16.3. Il bug è risolto in 16.4 (marzo 2023), ma MDM aziendale e aggiornamenti OEM lenti tengono in vita i dispositivi più vecchi. Mitigazione: non spedire mai AVIF senza una source WebP funzionante nello stesso <picture>, e non impostare mai un AVIF come src dell’<img> direttamente. Seguire i pattern della sezione 4 ti protegge già.

7. Il cheat sheet 2026

Scenario	Primario	Fallback	Encoder
Pagine statiche di marketing	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp in CI
Articoli di blog e documentazione	WebP q75	JPEG q80	compressore immagini gratuito (manuale) o Sharp (build)
Upload utente	WebP (client-side)	JPEG (browser senza codifica WebP)	browser-image-compression + Sharp lato server per AVIF
HDR / fotografia professionale	AVIF 10-bit q70	(nessuno: abbandona il fallback SDR o salta del tutto AVIF)	cavif + libavif modalità HEIF
Distribuzione CDN in tempo reale	Negoziato (AVIF o WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Due promemoria prima di spedire. Imposta sempre width e height sull’<img> per prevenire il CLS. Verifica sempre l’header Content-Type di produzione su almeno una risposta AVIF: una configurazione MIME rotta uccide silenziosamente AVIF in produzione più spesso di qualsiasi altro fallimento in questa lista.

FAQ

Mi serve ancora un fallback JPEG nel 2026?

Sì. AVIF raggiunge circa il 93% degli utenti globali e WebP circa il 97%. Resta una popolazione piccola ma reale (vecchio Edge, Firefox sotto la 93, iOS prima della 16.4, più la zona del bug di iOS 16.0–16.3) che ha bisogno di JPEG. Abbandona JPEG solo se le tue analytics mostrano traffico di fatto nullo da quei browser e puoi dimostrarlo.

Come tengo veloci le build CI quando la codifica AVIF è lenta?

Tre leve. Usa cavif --speed 6 o superiore (il default è 4) per scambiare ~5% di dimensione con ~3× di velocità. Parallelizza tra i core con GNU parallel o il worker pool del tuo build tool. E metti in cache per content hash così le immagini sorgenti immutate saltano del tutto l’encoder. Combinate, queste leve di solito tagliano il tempo di build AVIF sotto la vecchia baseline single-thread di WebP.

La decodifica WebP è davvero più veloce di AVIF?

Sì. libwebp decodifica circa 2–3× più velocemente di libavif, e il divario si allarga sui mobile di fascia bassa. Se il tuo collo di bottiglia di performance è la decodifica (una lunga galleria di immagini su un Android economico, ad esempio) e non la rete, WebP è il miglior formato primario. Per la maggior parte del traffico web, il risparmio di rete domina e AVIF vince comunque nel complesso.

Gli utenti iPhone possono vedere AVIF?

Gli iPhone con iOS 16.4 (marzo 2023) o successivi supportano AVIF nativamente in Safari. I dispositivi su iOS 16.0–16.3 hanno un bug di decodifica documentato che può far crashare Safari su certi file AVIF; le versioni iOS più vecchie non supportano AVIF affatto. Spedisci sempre un fallback WebP o JPEG dentro <picture> così gli utenti colpiti vedono qualcosa.

Devo usare `<picture>` o la negoziazione Accept-header?

I progetti più piccoli traggono beneficio da un markup <picture> esplicito: il comportamento è deterministico, puoi fare debug in locale e aggiunge forse 80 byte di HTML per immagine. I siti ad alto traffico vincono con la negoziazione Accept lato CDN: un URL per immagine, upgrade automatici di formato e il CDN mette in cache ogni formato separatamente. Un ibrido comune è <picture> per la UI dell’app e la negoziazione CDN per gli asset di marketing.

Perché il mio PNG è diventato più grande dopo la conversione in WebP?

Quasi sempre perché il PNG sorgente era già stato ottimizzato in modo aggressivo da pngquant, oxipng o ZopfliPNG, e l’encoder Canvas-based del browser non riesce a eguagliare quegli strumenti. Ricodifica dall’originale (export di Photoshop, master di un design tool, RAW) invece che dal PNG ottimizzato. Se il PNG ottimizzato è la tua unica sorgente, l’originale è già quasi ottimale: lascialo stare.

AVIF supporta la trasparenza?

Sì. AVIF supporta un canale alpha completo da 8 a 12 bit, e la sua codifica alpha è in genere più compatta di quella di WebP. Un’illustrazione PNG trasparente convertita in AVIF si riduce tipicamente del 50–70%, contro il 30–40% come WebP. AVIF è il sostituto più forte per il PNG trasparente in qualsiasi contesto che non richieda un output lossless esatto al pixel.

I browser possono codificare AVIF nativamente via toBlob(‘image/avif’)?

Solo Chrome 99+ al momento. Safari e Firefox sanno decodificare AVIF ma non sanno codificarlo via API Canvas a maggio 2026. Per la codifica AVIF lato client servono attualmente librerie WebAssembly come libavif-wasm o jsquash, che aggiungono 1–2 MB di payload. La maggior parte degli stack di produzione comprime in WebP nel browser e delega la generazione AVIF a un worker server.