Scegliere i formati di immagine per il web nel 2026: l'impero di JPEG, l'ascesa di AVIF e l'esilio di JPEG XL

Prendi una foto da 12 MP (4000 × 3000 pixel) ed esportala in sei modi. PNG: 24 MB. JPEG a qualità 90: 3,4 MB. WebP a parità di qualità visiva: circa 2,4 MB. AVIF a parità di qualità visiva: circa 1,7 MB. GIF, ridotto con dithering al suo tetto di 256 colori: 6 MB, con banding visibile ovunque. SVG non è nella lista: descrive disegni, e una fotografia non lo è.

Stessa immagine sullo schermo, un rapporto di 14× sul disco. Quel divario è ingegneria, non gusto. Ogni formato è un insieme di decisioni prese sotto i vincoli di un anno specifico, e quelle decisioni si fanno sentire ancora oggi nel peso delle tue pagine.

Questa è la versione decisionale di quell'esperimento: cosa fa davvero ogni formato ai tuoi pixel, quali browser lo decodificano a metà 2026, cosa sta servendo davvero il web, e una tabella finale che puoi incollare nel wiki del team.

I concorrenti, uno alla volta

JPEG (1992). Il meccanismo: divide l'immagine in blocchi di 8 × 8, trasforma ogni blocco in frequenze con la trasformata discreta del coseno, poi quantizza i dettagli fini verso lo zero secondo un modello della visione umana. Punti di forza: si decodifica su ogni dispositivo costruito dalla metà degli anni '90, codifica in fretta ed è eccellente sulle foto a tono continuo. Debolezze: niente trasparenza, niente animazione, ringing visibile intorno ai bordi netti e al testo, e una qualità che peggiora a ogni risalvataggio. Adatto alle fotografie e a tutto ciò che deve aprirsi assolutamente ovunque.

PNG (1996). Il meccanismo: interamente senza perdita. Ogni scanline viene filtrata con un predittore e poi impacchettata con DEFLATE, la stessa coppia LZ77 più Huffman che sta dentro gzip. Punti di forza: output esatto al pixel, alfa completo, supporto universale. La debolezza sono le foto: il rumore del sensore sconfigge il predittore, quindi uno scatto da 12 MP si comprime forse 1,5:1 rispetto ai pixel grezzi. Adatto a screenshot, catture di interfaccia, diagrammi e a tutto ciò che contiene testo o colore uniforme.

GIF (1987). Il meccanismo: compressione LZW su una tavolozza di al massimo 256 colori, con più fotogrammi impacchettati in un solo file. L'unico punto di forza rimasto è un'animazione che funziona ovunque, compresi i client email che non supportano i formati moderni. Le debolezze sono tutto il resto: 256 colori, trasparenza a un bit e file che fanno impallidire il video equivalente. Adatto a meme e piccoli loop di interfaccia.

SVG (2001). Il meccanismo: nessuno, nel senso raster. SVG è XML che descrive forme, tracciati e gradienti, e il renderer disegna i pixel alla risoluzione che lo schermo richiede. Punti di forza: indipendente dalla risoluzione, minuscolo per la grafica geometrica, stilizzabile con i CSS. Debolezze: funziona solo per contenuti genuinamente vettoriali, e i file patologici con migliaia di nodi e filtri pesanti possono costare più di una bitmap. Adatto a loghi, icone, grafici e diagrammi.

WebP (2010). Il meccanismo: la modalità con perdita prende in prestito la predizione intra-frame dal codec video VP8, mentre la modalità senza perdita usa predizione spaziale più riferimenti all'indietro in stile LZ77. Punti di forza: entrambe le modalità in un solo formato, alfa in modalità con perdita, animazione, e file dal 25 al 34% più piccoli di JPEG a parità di qualità nello studio condotto da Google stessa. Debolezze: un limite rigido di 16383 × 16383 pixel e un encoder che costa più CPU di libjpeg. Adatto a quasi tutto, ed è per questo che è diventato il percorso di aggiornamento predefinito per JPEG, PNG e GIF sul web.

AVIF (2019). Il meccanismo: fotogrammi singoli del codec video AV1, avvolti nel contenitore HEIF. Punti di forza: la migliore compressione con perdita che si possa distribuire in un browser, circa il 50% più piccola di JPEG a parità di qualità nei test di Netflix del 2020, più colore a 10 e 12 bit, HDR, alfa e animazione. Debolezze: la codifica è davvero lenta, non c'è rendering progressivo (l'immagine appare tutta insieme o per niente), e le impostazioni di qualità molto bassa sbavano le texture in un modo che l'onesto blocking di JPEG non fa. Adatto a fotografie e immagini hero, dove la dimensione del file conta di più.

HEIC (2015). Il meccanismo: fotogrammi HEVC, sempre in un contenitore HEIF. Punti di forza: compressione ai livelli di AV1 e formato di scatto predefinito su ogni iPhone dal 2017. La debolezza è legale più che tecnica: HEVC è avvolto nei patent pool, e ogni produttore di browser tranne Apple ha rifiutato di pagare. Appartiene ai rullini fotografici, non al web.

JPEG XL (2021). Il meccanismo: due motori sotto lo stesso tetto, VarDCT per il con perdita e una modalità modulare per il senza perdita, più un trucco che nessun altro formato possiede: può ricomprimere un JPEG esistente senza perdita fino a circa l'80% della dimensione originale, pixel bit-esatti inclusi. Punti di forza: decodifica progressiva, eccellenti rapporti senza perdita, fotografia ad alta fedeltà. La debolezza è l'adozione, che è soprattutto una questione di politica tra browser, trattata più sotto. Adatto alle pipeline fotografiche e agli archivi, e sui dispositivi Apple, al web.

Il supporto dei browser, metà 2026

Le versioni in cui ogni formato si è attivato per impostazione predefinita, secondo i dati di caniuse:

Tre dettagli di questa tabella meritano attenzione. AVIF su iOS è tecnicamente arrivato in Safari 16.0 ma senza animazione; è con la 16.4 che il supporto completo arriva sia su macOS che su iOS. Edge ha distribuito AVIF anni dopo Chrome pur essendo Chromium, perché Microsoft ha tenuto il decoder disattivato più a lungo di Google. E la riga di JPEG XL nasconde una storia insolita, che avrà una sezione tutta sua più sotto.

Copertura globale, secondo i numeri 2026 di caniuse: WebP è intorno al 97%, AVIF intorno al 93-94%. JPEG e PNG sono effettivamente al 100%, ed è improbabile che questo cambi.

La gerarchia della compatibilità

Raggruppati per portata, i formati si dividono in cinque livelli.

Il primo livello è l'insieme universale: JPEG, PNG, GIF e SVG. Si decodificano in ogni browser, ogni client email, ogni anteprima di sistema operativo e ogni chiosco di dieci anni fa. Se un file deve assolutamente aprirsi, viene distribuito in uno di questi quattro.

Il secondo livello è WebP, da solo. L'ultimo grande renitente era Safari, e Safari 14 ha chiuso quel divario nel settembre 2020. Quello che resta sono le installazioni di Internet Explorer e le vecchie WebView Android. Per un sito web, a differenza di un'email, WebP è un'impostazione predefinita sicura da circa cinque anni.

Il terzo livello è AVIF. Chrome lo aveva nel 2020, Firefox nel 2021, Safari nel 2022 (supporto completo nel marzo 2023 con la 16.4), ed Edge lo ha attivato di default nel gennaio 2024. Dall'inizio del 2024, ogni motore importante decodifica AVIF out of the box. I pochi punti percentuali rimanenti sono iPhone più vecchi e flotte Windows non gestite, ed è a questo che servono i fallback.

Il quarto livello è JPEG XL, bloccato. Apple lo distribuisce nativamente da Safari 17, settembre 2023. Google ha rimosso il decoder sperimentale di Chromium alla fine del 2022, con effetto da Chrome 110 nel febbraio 2023, per poi invertire la rotta e integrare un decoder basato su Rust (jxl-rs), distribuito in Chrome 145 nel febbraio 2026, ancora dietro un flag. Firefox ha un decoder dietro un flag da anni. Quindi il supporto di JPEG XL a metà 2026 significa tutti gli utenti Apple più la frazione evanescente di utenti Chrome e Firefox che attivano i flag, un gruppo troppo piccolo su cui costruire.

Il quinto livello è HEIC: Safari 17 sulle piattaforme Apple, nient'altro da nessun'altra parte. Più che un livello, è un ecosistema di un solo fornitore.

Cosa serve davvero il web

Supporto non è utilizzo. Il Web Almanac dell'HTTP Archive scansiona milioni di pagine reali e conta cosa servono, e l'edizione 2024 (l'ultima con dati completi sui media) si legge come un ghiacciaio in movimento. JPEG era ancora il singolo formato più diffuso con il 32% di tutte le immagini, ma sono otto punti pieni in meno rispetto al 40% del 2022. WebP ne ha raccolti tre arrivando al 12%. SVG ne ha guadagnati circa due. AVIF ha raggiunto circa l'1%, che suona come un errore di arrotondamento finché non lo leggi in relativo: una crescita di quasi 4× in due anni. ICO ha tenuto l'1,3%, quasi tutto favicon. E GIF, a 37 anni, ha in qualche modo guadagnato un punto.

Perché si muove così lentamente? Tre attriti spiegano la maggior parte del fenomeno. La cache dei CDN: le immagini stanno all'edge indicizzate per URL, e cambiare formato significa invalidare le cache e ricodificare intere librerie. I dispositivi vecchi: il grafico del supporto dice 97%, ma il 3% mancante si concentra nei telefoni Android economici e nelle flotte aziendali, e alcuni siti non possono permettersi di perdere una sola vendita per un'immagine rotta. L'inerzia degli strumenti: il CMS genera miniature JPEG perché ha sempre fatto così, lo strumento di design esporta PNG perché è il pulsante più in evidenza, e cambiare l'impostazione predefinita significa toccare una pipeline di build che non è di nessuno.

C'è anche il costo di codifica. Il vantaggio di compressione di AVIF si paga in CPU al momento dell'encoding, ed è per questo che i CDN di immagini lo fanno pagare e i team accorti pre-generano l'AVIF in fase di build o di upload anziché al volo.

Dove sta andando tutto questo

AVIF è la scommessa più sicura per i prossimi anni. È royalty-free per progettazione (l'Alliance for Open Media è stata fondata nel 2015 da Amazon, Cisco, Google, Intel, Microsoft, Mozilla e Netflix proprio per sfuggire ai patent pool in stile HEVC), gestisce con perdita e senza perdita in un'unica specifica, trasporta l'HDR e ha superato la soglia di supporto oltre la quale una catena di fallback non costa quasi nulla. I costi reali sono il tempo di codifica e la mancanza di decodifica progressiva. La pre-generazione risolve il primo; il secondo è un compromesso accettabile.

JPEG XL meritava un destino migliore di quello che ha avuto. Per merito tecnico è il formato più completo mai standardizzato: decodifica progressiva, la migliore modalità senza perdita, fotografia ad alta profondità di bit e ricompressione senza perdita dell'intero corpus JPEG esistente. Google lo ha ritirato da Chromium citando un interesse insufficiente dell'ecosistema, e la richiesta di ripristino è diventata una delle issue con più stelle nella storia del tracker di Chromium. Tre anni dopo Google ha invertito la decisione, ma a quel punto la finestra di adozione si era in gran parte chiusa. Mentre JPEG XL era in esilio, AVIF ha raccolto le integrazioni dei CDN, i plugin dei CMS e le caselle di spunta predefinite. JPEG XL vivrà come il preferito degli archivisti e come cittadino di prima classe sui dispositivi Apple. Aveva i requisiti tecnici per l'adozione mainstream, eppure l'ha mancata.

HEIC non diventerà un formato web. Il motivo non ha nulla a che vedere con la qualità. La decodifica HEVC richiede licenze di brevetto che i produttori di browser gratuiti si rifiutano di pagare da un decennio, e il web funziona con tecnologia royalty-free. Un formato che tre dei quattro motori principali non decodificano non è un formato web: è un problema di export che risolvi al confine.

La tecnica di transizione, nel frattempo, è ben consolidata e si presenta in due forme. Content negotiation lato server: il browser invia un header Accept con l'elenco di ciò che sa decodificare, e il server o il CDN sceglie la variante migliore per lo stesso URL. Lato client: l'elemento <picture>, che elenca i candidati e lascia che il browser prenda il primo che capisce:

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

L'<img> in fondo è il fallback universale, quindi niente si rompe da nessuna parte. È così che servi AVIF al 93% e JPEG a tutti gli altri senza mantenere due siti.

La tabella decisionale

Una breve nota sulle favicon, perché la riga della tabella tralascia alcuni dettagli. I browser moderni accettano favicon PNG e perfino SVG, ma ICO resta l'unico formato che ogni crawler, lettore RSS e browser datato capisce, e un file ICO può impacchettare diverse dimensioni in un solo contenitore. Se il tuo logo vive attualmente in un altro formato, da JPG a ICO, da WebP a ICO e da PNG a ICO producono un ICO multi-dimensione fatto come si deve direttamente nel tuo browser.

Convertire tra formati

La maggior parte delle conversioni discende dalle sezioni qui sopra. Quella di gran lunga più comune è tirare un HEIC fuori da un iPhone e metterlo in qualcosa che il resto del mondo riesca ad aprire. Da HEIC a JPG è la mossa giusta per condividere, visto che HEIC è già con perdita e JPEG evita che il danno si accumuli. Da HEIC a PNG congela lo stato attuale per l'editing, e da HEIC a WebP ha senso quando la destinazione è un sito web.

Poi c'è il triangolo JPEG, PNG, WebP. Portare un JPEG in un flusso di lavoro di design: da JPG a PNG, non perché guadagna qualità (impossibile) ma perché smette di perderne. Alleggerirlo per il web: da JPG a WebP. Nel verso opposto, per il software più vecchio: da WebP a JPG e da WebP a PNG. Uno screenshot PNG diretto a una galleria fotografica: da PNG a JPG, oppure da PNG a WebP quando vuoi file più piccoli conservando la trasparenza. Se erediti scansioni BMP non compresse, da BMP a JPG, da BMP a PNG e da BMP a WebP battono tutti l'invio per email di cimeli da svariati megabyte. Anche i documenti arrivano allo stesso bivio: da PDF a JPG per le pagine fotografiche, da PDF a PNG quando il testo deve restare nitido, e da PDF a WebP quando la pagina è diretta al web.

Ognuno di questi strumenti esegue la conversione in locale nel tuo browser, quindi il file non lascia mai il tuo dispositivo.

I formati continuano a cambiare. La regola no: abbina il codec al contenuto, e converti quando il contenuto cambia compito.