PNG vs JPG vs WebP: quale formato vince davvero nel 2026?

Siamo nel 2026 e PNG (1996), JPG (1992) e WebP (2010) sono tutti ancora in uso attivo in produzione sul web. Non è pigrizia — ognuno occupa un punto significativamente diverso sul triangolo di compromesso dimensione-file vs qualità vs funzionalità, e sostituirli tutti con un unico formato farebbe perdere informazioni che si vuole effettivamente conservare.

Questa è la storia più lunga dietro il nostro più breve confronto PNG vs JPG, con WebP aggiunto e la questione AVIF affrontata.

Il triangolo di compromesso

*APNG (PNG animato) esiste; il supporto è ampio ma il formato è raramente la scelta giusta nel 2026 — WebP e AVIF gestiscono entrambi meglio l’animazione.

Dove vince ciascuno

JPG vince quando

• L’asset è una fotografia e si ha bisogno di compatibilità universale (stampanti, client email datati, lettori di anteprima incorporati).
• L’asset subisce molti cicli di salvataggio — anche se ogni salvataggio perde qualità, la modifica JPG è il flusso di lavoro più supportato negli editor di immagini.
• Qualche consumer legacy delle immagini non gestirà nient’altro — sistemi incorporati, software di stampa vecchio di un decennio, ecc.

PNG vince quando

• L’asset ha bordi netti e aree di colore piatto (screenshot, catture UI, loghi, icone). Gli artefatti con perdita di JPG sono molto visibili su questi.
• È richiesta la trasparenza e WebP non è un’opzione (incorporamento PDF, alcuni flussi di lavoro di stampa).
• L’originale deve fare un viaggio andata e ritorno senza perdita — ri-salvare un PNG non lo degrada.

WebP vince quando

• La destinazione è il web e gli asset sono fotografie o simili. 25-35% più piccolo di JPG alla qualità visiva equivalente.
• È necessaria la trasparenza e il file va su una pagina web. La combinazione con perdita + alpha di WebP è imbattibile — PNG con alpha è enorme; AVIF è ancora più piccolo ma il supporto è più ristretto.
• È necessaria l’animazione e il pubblico è su browser moderni. L’animazione WebP è più piccola e di qualità superiore alla GIF animata.

AVIF vince quando

• Si è disposti a codificare lentamente per una migliore compressione. La codifica AVIF può essere da 10 a 100 volte più lenta di WebP, a seconda del codificatore. La decodifica è veloce.
• Il gap del 7% di supporto browser è accettabile per il proprio pubblico.
• Il peso delle immagini conta in modo sproporzionato — immagini hero sopra la piega per l’e-commerce, gallerie fotografiche, utenti mobile su connessioni a consumo.

L’albero decisionale

1. Deve essere renderizzato in qualsiasi contesto (email, lettore incorporato, stampa)? → JPG per le foto, PNG per la grafica.
2. La destinazione è strettamente il web E il pubblico è moderno? → WebP o AVIF.
3. Contenuto simile a fotografia, destinazione web, facile da codificare? → WebP.
4. Contenuto simile a fotografia, destinazione web, sito ricco di immagini, disposti a codificare lentamente? → AVIF.
5. UI / loghi / screenshot? → PNG.
6. Animazione? → WebP (o GIF animata solo se strettamente necessario).
7. Grafica vettoriale che è un logo o icona? → SVG. Non usare affatto un formato raster.
8. Meno di ~10 KB, usato una volta inline? → URI dati Base64 tramite il nostro strumento immagine-in-Base64.

Il pattern di fallback con l’elemento picture

Per la massima compatibilità con la minima dimensione del file, usare l’elemento HTML <picture> con fallback di formato:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="..." />
</picture>

Il browser sceglie il primo formato supportato. Chrome moderno riceve AVIF; Safari 14+ riceve WebP; il 3% su browser vecchi ricade su JPG. Il costo è la codifica di tre versioni; il beneficio è il formato corretto su ogni dispositivo.

Le nostre raccomandazioni

• Screenshot UI e loghi: PNG. Non pensarci troppo.
• Fotografie hero: AVIF + fallback WebP + fallback JPG tramite <picture>.
• Foto long-tail e immagini blog: WebP, fallback JPG. AVIF solo se si ha una pipeline di build che lo produce a basso costo.
• Contenuto animato: WebP (o video — a dimensioni significative un MP4 breve batte una WebP animata).
• Icone: SVG.

Usare il nostro cluster di conversione immagini per i cambi di formato. Ogni conversione gira nel browser — nessun caricamento, nessuna attesa, nessun compromesso di qualità da un servizio lato server.

Esempio pratico: immagine hero in tre formati

Sorgente: una fotografia 3000×2000 a 24 bit che pesa 17,4 MB come BMP non compresso. Codificata a qualità visivamente equivalente (SSIM ≥ 0,98 rispetto alla sorgente) con le impostazioni predefinite del codificatore:

• JPG (qualità 82): 612 KB.
• WebP (qualità 80): 388 KB — 37% più piccolo di JPG.
• AVIF (CRF 28): 241 KB — 61% più piccolo di JPG, 38% più piccolo di WebP.
• PNG (senza perdita): 14,8 MB — 24 volte più grande di JPG, inutilizzabile come hero web.

Tempi di codifica su un laptop M2 del 2024 usando rispettivamente libjpeg-turbo,libwebp e libavif: JPG 0,08s, WebP 0,34s, AVIF 4,2s. Il rallentamento di codifica di 50× di AVIF è il vero motivo per cui non è ancora il formato predefinito. Per una pipeline di build che produce immagini hero una volta al momento del deploy, quel costo si ammortizza; per avatar caricati dagli utenti ridimensionati al volo, è proibitivo.

Errori comuni

• Salvare un JPG ripetutamente.Ogni salvataggio ri-quantizza i coefficienti DCT; la qualità degrada anche se la differenza sullo schermo è inizialmente invisibile. Conservare l’originale (PNG, TIFF o RAW) e riesportare in JPG solo al momento della pubblicazione. Usare il nostro strumento PNG in JPG per il passaggio finale.
• Usare PNG-24 dove PNG-8 è sufficiente. Uno screenshot di una UI con 256 colori distinti può stare in PNG-8 (indicizzato a 8 bit) a un terzo della dimensione di PNG-24 con output visivo identico. La maggior parte degli editor di immagini non predispone PNG-8 — esportare esplicitamente a esso per le palette indicizzate.
• Saltare il fallback <picture> per AVIF.Anche il 93% di supporto globale significa che 1 visitatore su 14 riceve un’immagine rotta. Il fallback aggiunge zero peso per i browser che caricano prima AVIF.
• Trattare la modalità senza perdita di WebP come sostituto di PNG.WebP-senza perdita è eccellente per le fotografie codificate senza perdita; per gli asset UI a colori indicizzati, PNG-8 è spesso più piccolo. Testare entrambi prima di standardizzare.
• Rimuovere EXIF e ICC incondizionatamente. Il profilo colore (ICC) è importante per le fotografie visualizzate su display wide-gamut. Rimuovere EXIF per la privacy, mantenere ICC per la fedeltà.

Per i compromessi dei formati di compressione spiegati a livello di codec, vedere la nostra guida su come ridimensionare le immagini senza perdita di qualità.