JPEG XL: il formato immagine che tutti aspettavano è finalmente nei browser

Per anni JPEG XL è stato il formato immagine “migliore” che nessun browser voleva davvero. Nel 2022 Chrome ne aveva tolto il supporto, e il formato sembrava destinato a restare una curiosità per addetti ai lavori.

Oggi, a metà ottobre 2026, la situazione si è ribaltata: Chrome 155 lo supporta di default, Firefox 158 (uscito il 13 ottobre) lo attiva a sua volta e Safari lo capisce già dal 2023. Manca ancora un tassello importante, Edge.

Scrivo software dal 1981 e ho visto arrivare GIF, JPEG, PNG, WebP e AVIF. Ogni volta la domanda è la stessa: cosa cambia davvero per chi pubblica un sito? Qui provo a rispondere senza hype, con le fonti in fondo. È un tema più terra terra rispetto a quelli sull’intelligenza artificiale di cui scrivo di solito, ma altrettanto concreto.

JPEG XL non è “un JPEG più piccolo”. È un formato pensato per sostituire in un colpo solo JPEG, PNG e GIF. Può comprimere con o senza perdita, gestisce la trasparenza, le animazioni, i livelli e le immagini HDR con gamma cromatica ampia, arriva a profondità colore molto alte e supporta immagini enormi, fino a un terapixel.

Ha anche la decodifica progressiva: la pagina mostra prima una versione sfocata dell’immagine che si completa man mano che i dati arrivano, utile su connessioni lente.

Un’altra differenza rispetto a WebP e AVIF è l’origine: quelli derivano da codec video, JPEG XL nasce per le immagini fisse. Per le fotografie di qualità alta è dove tende a dare il meglio, ma il risultato dipende sempre dal programma che lo codifica e dalle impostazioni.

La parte che mi interessa di più, da chi ha un sito pieno di vecchie foto, è questa: un JPEG può essere ricompresso in JPEG XL senza alcuna perdita e il file risultante è, di norma, più piccolo di circa il 20%. Il passaggio è reversibile: dal file JPEG XL si può tornare al JPEG originale, bit per bit.

Non è il miracolo che si legge in certi post (un -68% sul peso, per esempio, lo ottenete solo rinunciando a qualcosa), ma è un risparmio gratuito, senza toccare la qualità. Nell’immagine qui sotto i numeri sono inventati: servono a mostrare il percorso, non a misurarlo.

AVIF è già da tempo supportato dai principali browser, e per molti siti è la scelta “moderna” di oggi. Il confronto con JPEG XL non ha un vincitore unico: in generale AVIF tende a reggere meglio a qualità bassa, dove contano i byte, mentre JPEG XL tende a vincere ad alta qualità, dove conta la fedeltà. Ma dipende molto dall’encoder e dall’immagine.

Qui sul blog il plugin che uso già genera WebP e AVIF a partire dai miei PNG, ed è così che il sito si tiene leggero senza che io me ne occupi a mano. È lo stesso ragionamento che applichiamo ai siti dei clienti, quando lavoriamo su WordPress: il formato è un dettaglio, la velocità percepita dall’utente no.

Il punto è che WordPress, oggi, non sa che farsene di un file JPEG XL. Per quanto ho potuto verificare, il supporto non è nel core: la richiesta su Trac (il ticket #52788) è stata chiusa come “forse più avanti”, perché il supporto dei browser era ancora troppo limitato. E chi prova a caricare un file .jxl nella libreria media se lo vede rifiutare.

Il problema non è solo il permesso di caricamento. Quando carichi un’immagine, WordPress non si limita a salvarla: la ridimensiona e genera le miniature (thumbnail, medium, large e le altre dimensioni che servono al tema) usando una libreria del server, GD oppure Imagick. GD non sa trattare il JPEG XL; Imagick può farlo, ma solo se il server è compilato con il supporto giusto. Senza questo passaggio WordPress non ha modo di creare le versioni intermedie, né di mostrarvi l’anteprima in libreria.

Con l’AVIF è andata diversamente: WordPress lo accetta dalla versione 6.5, lo carica e genera le miniature come per un JPEG. L’ho verificato caricando l’immagine di prova che trovate più sotto. Per il JPEG XL, invece, non ho trovato un plugin affidabile che gestisca in un colpo solo caricamento, miniature, conversione e formato di riserva: ci sono workaround, ma nessuno che mi senta di consigliare su un sito vero.

Se il sito fosse costruito con Astro, Next.js o un altro framework moderno, il discorso sarebbe diverso: lì la pipeline delle immagini la decido io, in fase di build o di richiesta, e posso scegliere formato, dimensioni e formato di riserva senza aspettare che un CMS lo permetta. Ma è un’altra storia, e la racconterò in un altro articolo.

Per ora il blog gira su WordPress, e con WordPress per il JPEG XL bisogna aspettare.

L’opzione migliore, per ora, è appoggiarsi a un plugin di terze parti. Io uso CompressX, che converte le immagini in WebP e in AVIF e le serve ai browser che le supportano, lasciando l’originale come formato di riserva. È la scelta che ho fatto su questo blog: AVIF per primo, e il file originale per chi non lo legge.

Il risultato è concreto. Le immagini di questo articolo sono PNG da circa 1,9 MB ciascuna: la libreria media le abbina a una versione AVIF da 41-49 KB e a una WebP da 60-70 KB. Sono illustrazioni a colori piatti, quindi il risparmio è estremo; con una fotografia vera sarà meno spettacolare, ma resta importante.

Per vedere le differenze a occhio e a byte, ho preso una delle immagini dell’articolo e l’ho salvata nei formati principali, ciascuno con la sua dimensione indicata sotto.

Una sola immagine e impostazioni diverse per formato: non è un test scientifico, e a parità di impostazioni il risultato cambierebbe. Il JPEG XL è stato generato qui, fuori da WordPress, perché sul blog non si può caricare.

Una prova a parte, sul tema della conversione: ho ricompresso senza perdita il JPEG da 151 KB in JPEG XL e il file è sceso a circa 127 KB, intorno al 16% in meno, in linea con il 20% di cui si parla di solito.

Il principio è semplice: CompressX non tocca l’originale. Accanto a ogni immagine della libreria crea una copia WebP e una AVIF, e poi sceglie quale servire. La conversione avviene sul tuo server, senza passare da servizi esterni. Nella libreria media, in modalità elenco, ogni file mostra il peso originale, quello WebP e AVIF e la percentuale risparmiata.

Le impostazioni che contano, con quello che ho scelto io:

• Formati di uscita: WebP e AVIF, attivabili separatamente. Il plugin controlla se il server ha i codec necessari e, se mancano, disattiva il formato.
• Libreria di conversione: GD oppure Imagick. Il mio blog usa GD.
• Qualità: c’è la modalità generale (una qualità fissa per tutte le immagini, di default 80 per WebP e 60 per AVIF, ed è quella che uso), quella senza perdita (99) e una modalità “smart” a pagamento che adatta la qualità alla dimensione.
• Dimensioni da elaborare: l’originale e le miniature che WordPress genera (thumbnail, medium, large e le altre), da scegliere una per una.
• Ottimizzazione in blocco: scansiona la libreria e converte le immagini già caricate, a lotti.
• Nuovi caricamenti: elaborati in automatico, con un breve ritardo configurabile (da 1 a 10 minuti) per non appesantire il server.
• Come arrivano al visitatore: tre opzioni. Le regole di riscrittura nel file .htaccess (il default), una variante compatibile, oppure il tag picture. Io uso il tag picture: il browser sceglie da solo il formato migliore tra quelli che gli passo, con l’originale come ultima scelta.
• Extra: rimozione dei dati EXIF (io li elimino), tenere l’originale quando la versione convertita risulta più grande, escludere intere cartelle o i PNG dalla conversione, ridimensionare le immagini troppo grandi.
• CDN: integrazione con Cloudflare e BunnyCDN per svuotare la cache dopo le conversioni.

Il plugin stesso segnala oltre 61 MB di immagini ottimizzate sul blog. Resta un lavoro in più rispetto a un sistema che gestisse il JPEG XL in modo nativo, ma è gestibile: si imposta una volta, e poi non ci si pensa più.

Dipende da cosa intendiamo per “standard”. Con Chrome, Firefox e Safari che lo leggono, la copertura è ormai ampia, e Edge, essendo basato su Chromium, ha buone ragioni per seguire. Ma per quanto ho potuto verificare, una conferma ufficiale non c’è ancora: finché non arriva, JPEG XL resta un formato da servire insieme a un’alternativa, con l’elemento picture o con la negoziazione sul server, ora che Firefox lo dichiara anche nell’header Accept.

Poi c’è il lato CMS, e per WordPress è quello che pesa di più: finché il core non lo gestisce, JPEG XL resta fuori dalla libreria media. Per questo le immagini di questo articolo sono PNG, convertite poi in WebP e AVIF. L’idea di caricarle in JPEG XL come “easter egg” è simpatica, e quando i numeri lo permetteranno la riprendo volentieri.

La mia posizione, in breve: vale la pena provarlo, non vale ancora la pena puntarci tutto. Più avanti la copertura salirà e sarà un tema anche di SEO e di velocità: ne abbiamo parlato in La SEO è morta, lunga vita alla SEO.

E voi, lo avete già provato sui vostri siti? Raccontatemelo nei commenti o scrivetemi direttamente.

• MDN, Firefox 158 release notes
• Can I use, JPEG XL image format
• Mozilla Hacks, Intent to ship: JPEG XL
• Gigazine, Google Chrome 155
• Wikipedia, JPEG XL
• WordPress Trac, Ticket #52788: Add JPEG XL support
• WordPress.org, CompressX — AVIF & WebP Converter
• Francamente.tech, Intelligenza Artificiale: che fastidio!
• F.technology, WordPress
• F.technology, La SEO è morta, lunga vita alla SEO

Provalo tu: la stessa immagine in quattro formati, con i pesi misurati e la spiegazione di come ho inserito il JPEG XL in questa pagina.