Formati immagine per il web nel 2026: JPEG, PNG, WebP, AVIF, JPEG XL e SVG

La scelta del formato immagine è una delle variabili più sottovalutate che impattano direttamente sui Core Web Vitals, in particolare sull’LCP (Largest Contentful Paint). Dal 2021 lo scenario è cambiato radicalmente: WebP ha raggiunto la compatibilità quasi universale, AVIF è diventato production-ready sui principali browser, JPEG XL è stato riabilitato in WebKit e le build pipeline moderne generano varianti multiple per content negotiation via header Accept. In questa guida aggiornata al 2026 analizzo ogni formato per caso d’uso, con dati di compressione misurati, livelli di supporto reali e snippet di implementazione HTML.

Per un inquadramento più ampio sull’ottimizzazione lato SEO rimando alla guida all’ottimizzazione delle immagini per Google e all’articolo su come far apparire le immagini in Google News. Per gli attributi lato HTML, utile il pezzo su alt vs title delle immagini.

Raster vs vettoriale: le due famiglie

Ogni formato immagine appartiene a una di due famiglie: raster (bitmap) o vettoriale. La scelta determina scalabilità, peso del file e casi d’uso validi.

Le immagini raster codificano l’informazione come griglia di pixel. Ogni pixel ha un valore di colore in uno spazio definito (sRGB, Display P3, Rec. 2020 per HDR). La risoluzione è fissa: ingrandire significa interpolare, con perdita di nitidezza. Appartengono a questa famiglia JPEG, PNG, GIF, WebP, AVIF, JPEG XL, HEIC, BMP e TIFF.

Le immagini vettoriali descrivono la geometria (linee, curve, riempimenti) come istruzioni matematiche. Sono intrinsecamente scalabili senza perdita. Sul web l’unico formato vettoriale rilevante è SVG.

Nota sul downsampling: il downsampling è la riduzione della risoluzione di un’immagine raster tramite algoritmi di ricampionamento (bilineare, bicubico, Lanczos). È un’operazione lossy: una volta ridotta, l’informazione ad alta frequenza non è recuperabile. Nei workflow web si usa per generare le varianti responsive servite tramite srcset (es. da un master 2400px → 800, 1200, 1600px per breakpoint).

Parametri chiave delle immagini raster:

• Risoluzione: pixel totali (es. 1920×1080). Il DPI è una metrica di stampa, irrilevante per il web.
• Profondità di colore: bit per canale. 8 bpc è lo standard web, 10/12 bpc per HDR (AVIF, JPEG XL).
• Spazio colore: sRGB è lo standard web, Display P3 cresce con Apple e display moderni.
• Canale alpha: presenza di trasparenza. PNG, WebP, AVIF, JPEG XL lo supportano; JPEG no.
• Tipo di compressione: lossy (JPEG, WebP lossy, AVIF lossy) o lossless (PNG, WebP lossless, AVIF lossless, JPEG XL lossless).

JPEG

JPEG (Joint Photographic Experts Group) è il formato raster lossy dominante dal 1992. Si basa su trasformata DCT (Discrete Cosine Transform) a blocchi 8×8, quantizzazione e codifica entropica. È ottimizzato per immagini fotografiche con gradienti continui e alto contenuto cromatico.

Punti di forza: compatibilità universale (ogni browser, sistema operativo e software grafico degli ultimi 30 anni), encoder estremamente maturi (MozJPEG, libjpeg-turbo), dimensioni ragionevoli per fotografie.

Limiti: nessun supporto canale alpha, artefatti di blocco visibili ad alta compressione, nessun supporto nativo HDR o wide gamut, efficienza di compressione superata di 25-50% da WebP e AVIF.

Quando usarlo nel 2026: come fallback universale nel tag <picture> dopo AVIF e WebP. Per pipeline moderne, encoder come MozJPEG generano JPEG fino al 10-15% più leggeri di libjpeg standard a parità di qualità percettiva.

Differenza tra JPG e JPEG

Non c’è alcuna differenza tecnica: JPG e JPEG sono lo stesso formato, identificato nel registro IANA con MIME type image/jpeg. Entrambi puntano allo standard ISO/IEC 10918. L’estensione a tre caratteri .jpg deriva da un vincolo storico di Windows (file system FAT-16 con naming 8.3) che limitava le estensioni a tre lettere. Su sistemi Unix e macOS la variante .jpeg è altrettanto valida. Convertire da .jpeg a .jpg significa rinominare il file: il contenuto binario è identico.

JPEG progressivo vs baseline

Il JPEG baseline viene decodificato dall’alto verso il basso. Il JPEG progressivo codifica l’immagine in scansioni multiple a risoluzione crescente: la prima scansione fornisce un’anteprima sfuocata dell’intera immagine, le successive raffinano i dettagli. Per immagini sopra i 10 KB il progressivo è generalmente più leggero del baseline e migliora la perceived performance sul primo render. MozJPEG abilita il progressive encoding di default.

PNG

PNG (Portable Network Graphics) è stato creato nel 1996 come rimpiazzo libero di GIF. Usa compressione lossless basata su filtri per-riga + Deflate (lo stesso algoritmo di ZIP e gzip). È il formato lossless storico del web.

Varianti in uso:

• PNG-8: palette indicizzata fino a 256 colori + 1 bit di trasparenza (on/off). File leggeri, storicamente usato per icone e grafica semplice.
• PNG-24: 24 bit di colore reale (16,7M colori), senza canale alpha.
• PNG-32: 24 bit di colore + 8 bit di canale alpha (trasparenza graduata). Lo standard attuale quando serve trasparenza lossless.

Quando usarlo nel 2026: screenshot, loghi con trasparenza alpha, UI asset con testo nitido e bordi netti. Per fotografie PNG è sconsigliato perché produce file 3-10× più pesanti di JPEG. Se serve trasparenza lossless e dimensioni contenute, WebP lossless è quasi sempre superiore (circa 26% più leggero a parità di qualità, dato Google).

Per ottimizzare PNG esistenti, tool come pngquant (quantizzazione a palette con dithering) o oxipng/zopflipng (ricompressione Deflate) riducono la dimensione del 40-70% senza cambiare formato.

GIF

GIF (Graphics Interchange Format) è stato pubblicato da CompuServe nel 1987. Palette indicizzata a 256 colori, compressione LZW lossless, supporto multi-frame per animazioni. Nel 2026 è di fatto un formato legacy.

Perché evitarlo per nuove implementazioni:

• Limite a 256 colori per frame: fotografie o animazioni complesse appaiono dithered.
• Trasparenza on/off (1 bit), senza canale alpha graduato.
• Efficienza di compressione pessima: un’animazione di 2 secondi 480×270 può pesare 3-5 MB in GIF contro 200-500 KB in WebP animato o MP4.

Sostituti moderni:

• Video MP4/WebM tramite tag <video autoplay muted loop playsinline>. Rapporto di compressione 10-20× migliore. Adottato da Twitter/X, Reddit e dalla maggior parte delle piattaforme social come “GIF replacement”.
• WebP animato e AVIF animato: mantengono la semantica di “immagine” (girano dentro <img>) con compressione moderna.

Unico caso residuo di uso: integrazione con sistemi legacy (client email, vecchi CMS) che non supportano video o WebP animato.

WebP

WebP è un formato sviluppato da Google (2010) basato sul codec video VP8 (variante intra-frame). Supporta compressione lossy, lossless, canale alpha e animazioni. Dal 2020-2021 la compatibilità browser ha raggiunto il 98%+ secondo i dati di caniuse.com: Chrome, Edge, Firefox, Safari 14+, tutte le versioni moderne di iOS e Android.

Numeri di compressione dichiarati da Google:

• WebP lossy: 25-35% più leggero di JPEG a parità di qualità SSIM.
• WebP lossless: circa 26% più leggero di PNG.
• WebP animato: 64% più leggero di GIF, 19% più leggero di APNG.

Posizione nel 2026: WebP è il default di fatto delle pipeline di ottimizzazione immagini. È il secondo candidato nel tag <picture> dopo AVIF, e il primo candidato se la compatibilità con browser datati è un requisito. Tool di encoding di riferimento: cwebp (libwebp), sharp per Node.js, Pillow per Python.

AVIF

AVIF (AV1 Image File Format) è un formato basato sul codec video AV1 (Alliance for Open Media: Google, Netflix, Mozilla, Amazon, Intel). Standardizzato nel 2019. Supporta HDR, wide color gamut, profondità fino a 12 bpc, canale alpha, animazioni.

Efficienza: a parità di qualità percettiva, AVIF produce file circa 50% più leggeri di JPEG e 20-30% più leggeri di WebP. Il vantaggio è più marcato a basse qualità target (ideale per thumbnail e immagini above-the-fold fortemente ottimizzate).

Compatibilità nel 2026 (dati caniuse):

• Chrome: da v85 (agosto 2020).
• Firefox: da v93 (ottobre 2021).
• Safari: da v16 / iOS 16 (settembre 2022).
• Edge: allineato a Chromium.
• Global support: oltre il 95%.

Trade-off noti:

• Encoding computazionalmente costoso: l’encoder AV1 di riferimento (libaom) è 5-50× più lento di cwebp. Per pipeline di produzione si usano rav1e o SVT-AV1, molto più veloci a parità di qualità.
• Alcune implementazioni mostrano artefatti di smoothing su texture sottili (pelle, dettagli ad alta frequenza) a qualità aggressive. Calibrare il CRF sui propri asset.
• Tool grafici legacy (Photoshop senza plugin, vecchie versioni di GIMP) non leggono AVIF nativamente.

Quando usarlo: come primo candidato nel tag <picture>. Particolarmente vantaggioso sull’immagine LCP, dove ogni KB risparmiato impatta direttamente sul punteggio Core Web Vitals.

JPEG XL

JPEG XL (estensione .jxl, MIME image/jxl) è uno standard ISO/IEC 18181 ratificato tra 2021 e 2022. Nasce come successore naturale di JPEG con una feature unica: ricodifica lossless di JPEG esistenti con circa 20% di riduzione peso, reversibile al bit esatto. Supporta HDR, wide gamut, profondità 32 bpc, alpha, animazioni, progressive decoding avanzato.

Efficienza: compete con AVIF a qualità medio-alte e lo supera a qualità molto alte (near-lossless). Vantaggio di circa 55-60% su JPEG legacy.

Stato del supporto browser:

• Safari: supporto nativo da Safari 17 (settembre 2023) su macOS Sonoma, iOS 17, iPadOS 17. WebKit abilitato di default.
• Firefox: dietro flag image.jxl.enabled, non abilitato di default.
• Chrome/Edge: rimosso da Chromium 110 (2023), la discussione è stata riaperta dopo forti pressioni dalla community e da Adobe. Verificare lo stato corrente su chromestatus.com prima di deployare in produzione.

Quando usarlo nel 2026: come formato aggiuntivo nel <picture> prima di AVIF per servirlo a Safari. La content negotiation va gestita via header Accept: image/jxl o tramite <source type="image/jxl">. Per archivi fotografici e workflow DAM è già un’opzione interessante grazie alla ricompressione lossless JPEG.

SVG

SVG (Scalable Vector Graphics) è uno standard W3C basato su XML. Descrive grafica vettoriale tramite primitive geometriche (path, rect, circle, polygon) con attributi di stile CSS-compatibili. Supporto browser universale (IE9+).

Casi d’uso canonici:

• Loghi, icone, pittogrammi.
• Grafici e visualizzazioni dati (D3.js, Chart.js).
• Illustrazioni piatte con poche forme.
• Asset UI che devono scalare per display ad alta densità (Retina, 3x, 4x) senza asset multipli.

Ottimizzazione: sempre passare gli SVG generati da Illustrator/Figma attraverso SVGO. Rimuove metadata (commenti Adobe, attributi Inkscape, DOCTYPE inutili) riducendo il peso del 40-70%. Impostare removeViewBox: false per preservare la scalabilità.

Rischio sicurezza: SVG è XML eseguibile. Può contenere <script>, gestori onload/onerror, link javascript:. Mai servire SVG da user upload senza sanitization: vettore di XSS ben documentato. Tool di riferimento: DOMPurify con profilo SVG, o svg-sanitizer lato PHP. In alternativa, per SVG untrusted, servirli con Content-Disposition: attachment o da un sottodominio isolato con CSP restrittiva.

HEIC e HEIF

HEIF (High Efficiency Image Format) è un container ISO/IEC 23008-12. HEIC è la variante che usa codec HEVC (H.265). Apple lo ha adottato come formato default per le foto iPhone dal 2017 (iOS 11).

Efficienza: 40-50% più leggero di JPEG a parità di qualità.

Perché non è un formato web: la compatibilità è limitata all’ecosistema Apple (Safari su macOS/iOS) e manca nei browser Chromium e Firefox per vincoli di licenza HEVC (royalty-based, non open-source). Servire HEIC su una pagina web significa che la maggior parte dei visitatori riceve un broken image.

Cosa fare in pratica: se ricevi foto .heic da iPhone, convertile in WebP/AVIF prima del caricamento. Tool: ImageMagick con delegate libheif, heif-convert, o l’export automatico di iOS impostato su “Più compatibile” (che esporta in JPEG).

BMP e TIFF

BMP (Bitmap, .bmp): formato raster Microsoft non compresso (o compresso con RLE marginale). Un’immagine 1920×1080 a 24 bit pesa circa 6 MB. Irrilevante sul web: usarlo significa servire file 10-30× più pesanti del necessario. Il termine “bitmap” è spesso usato come sinonimo generico di “immagine raster”, ma tecnicamente BMP è un formato file specifico.

TIFF (Tagged Image File Format, .tif/.tiff): container flessibile, supporta lossless (LZW, ZIP, Deflate), lossy (JPEG in TIFF), layer, CMYK, profondità fino a 32 bpc. È lo standard nei workflow di stampa professionale e archivi fotografici. Non supportato dai browser: va convertito in JPEG/WebP/AVIF per la pubblicazione web.

Tabella comparativa dei formati

Formato	Compressione	Alpha	Animazione	HDR	Supporto 2026	Caso d’uso
JPEG	Lossy	No	No	No	100%	Foto, fallback universale
PNG	Lossless	Sì (8 bit)	No (APNG sì)	No	100%	Screenshot, loghi lossless
GIF	Lossless LZW	Sì (1 bit)	Sì	No	100%	Legacy
WebP	Lossy + Lossless	Sì (8 bit)	Sì	No	~98%	Default moderno
AVIF	Lossy + Lossless	Sì	Sì	Sì	~95%	Primo in <picture>, LCP
JPEG XL	Lossy + Lossless	Sì	Sì	Sì	Solo Safari 17+	Archivi, DAM
SVG	Vettoriale	Sì	Sì (SMIL/CSS)	N/A	100%	Loghi, icone, grafici
HEIC	Lossy HEVC	Sì	Sì	Sì	Solo Apple	Foto iOS, NON web

Quale formato scegliere per ogni scenario

Decisione operativa per casi d’uso tipici di un progetto web:

• Fotografia (blog, e-commerce, magazine): AVIF + WebP + JPEG come fallback, servito via <picture>.
• Immagine LCP (above-the-fold, hero): AVIF prioritario, preload via <link rel="preload" imagesrcset>, compressione aggressive sulla variante mobile, fetchpriority="high".
• Logo, icone, pittogrammi: SVG inline (nessuna request aggiuntiva, stylable via CSS).
• Screenshot UI con testo nitido: PNG-24 o WebP lossless.
• Loghi con trasparenza su sfondi complessi: WebP lossless o PNG-32.
• Animazioni brevi: video MP4/WebM in <video>, WebP animato come alternativa dentro <img>.
• Grafici dati / dashboard: SVG (statici) o Canvas (dinamici ad alta densità di punti).
• Email HTML: JPEG e PNG. WebP ha supporto incompleto nei client (Outlook desktop non lo legge); AVIF fuori discussione.

Implementazione con picture e content negotiation

Il pattern canonico per servire la variante più moderna supportata dal client è il tag <picture> con <source> multiple. Il browser sceglie la prima sorgente di cui supporta il type MIME.

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

Punti critici:

• L’ordine delle <source> conta: dal più moderno al più compatibile.
• width e height sul tag <img> sono obbligatori per evitare Cumulative Layout Shift (CLS).
• loading="lazy" va applicato solo alle immagini below-the-fold. Sull’immagine LCP usare loading="eager" (default) e fetchpriority="high".
• Per immagini responsive, combinare <source> con srcset e sizes per servire risoluzioni diverse per breakpoint.

Alternativa: content negotiation via header. Il server legge l’header Accept della request e serve dinamicamente la variante corretta allo stesso URL. Esempio Nginx:

map $http_accept $img_suffix {
    default        "";
    "~*image/avif" ".avif";
    "~*image/webp" ".webp";
}

location ~* \.(jpg|jpeg|png)$ {
    try_files $uri$img_suffix $uri =404;
    add_header Vary Accept;
}

L’header Vary: Accept è critico: senza di esso CDN e proxy servirebbero la variante del primo client a tutti i successivi, anche incompatibili. Cloudflare Polish, Fastly Image Optimizer e AWS CloudFront Functions implementano questo pattern in modo trasparente.

Impatto sui Core Web Vitals e LCP

La scelta del formato immagine impatta direttamente due Core Web Vitals:

• LCP (Largest Contentful Paint): nel 70-80% delle pagine desktop e mobile l’elemento LCP è un’immagine. Passare da JPEG a AVIF su un’hero da 1,2 MB porta il peso a 400-500 KB, con guadagno LCP di 300-800 ms su connessioni 4G.
• CLS (Cumulative Layout Shift): indipendente dal formato, dipende dalla dichiarazione di width/height o aspect-ratio CSS. Sempre obbligatoria.

Per la misurazione empirica del delta, non affidarsi a singoli test Lighthouse: usare CrUX (Chrome User Experience Report) o Search Console > Esperienza sulla pagina per dati field reali prima e dopo il cambio formato. Un A/B test sul formato con monitoraggio LCP via RUM (Real User Monitoring) è il golden standard per giustificare la complessità di una pipeline AVIF.

Domande frequenti

Che differenza c’è tra JPG e JPEG

Nessuna differenza tecnica. Sono lo stesso formato, stesso MIME type image/jpeg. La variante a tre caratteri .jpg è un retaggio del file system Windows 8.3. Rinominare .jpeg in .jpg non cambia un bit del file.

Cosa significa downsampling

Il downsampling è la riduzione della risoluzione di un’immagine raster tramite algoritmi di ricampionamento (bilineare, bicubico, Lanczos). Operazione lossy. Nei workflow web si usa per generare le varianti responsive servite tramite srcset.

Come convertire da PNG a JPG

Tool da linea di comando: convert input.png -quality 85 output.jpg (ImageMagick), oppure cjpeg -quality 85 input.png > output.jpg (MozJPEG). La conversione è distruttiva sulla trasparenza: il canale alpha del PNG viene rimpiazzato da un colore di sfondo (default bianco). Se la trasparenza è richiesta, convertire in WebP o AVIF.

Aprire WebP con Photoshop

Photoshop supporta WebP nativamente dalla versione 23.2 (2022). Per versioni precedenti, installare il plugin WebPShop di Google. AVIF è supportato nativamente da Photoshop 24.x+.

WebP o AVIF, quale scegliere

Entrambi. Il pattern moderno è servirli entrambi tramite <picture>: AVIF come prima scelta (meno peso, supporto ~95%), WebP come secondo fallback (~98%), JPEG/PNG come fallback finale. Scegliere solo WebP è accettabile se il costo di generazione AVIF in pipeline è proibitivo.

PNG-8 o PNG-24

PNG-8 per grafica con tinte piatte e trasparenza on/off (icone semplici, bandiere, loghi monocromatici). PNG-24/32 per screenshot, loghi con gradient, immagini con alpha graduato. In entrambi i casi, WebP lossless è quasi sempre preferibile nel 2026.