Apri un file PNG in un editor esadecimale. I primi otto byte:
89 50 4E 47 0D 0A 1A 0A
Questa è la firma PNG. Ogni decoder PNG la controlla. Il primo byte 0x89 è deliberatamente alto — impedisce agli editor di testo naïf di trattare il file come ASCII. 50 4E 47 compone "PNG" in ASCII. 0D 0A è un ritorno a capo DOS, 1A è il marcatore di fine file DOS, e 0A è un avanzamento riga Unix. I progettisti hanno incorporato questi caratteri di fine riga in modo che i trasferimenti FTP in modalità testo corrompessero immediatamente il file, costringendo gli utenti a trasferire in modalità binaria. Era un piccolo atto di paranoia da parte di sviluppatori che avevano appena visto un formato brevettato trasformarsi in un'arma legale.
Il PNG è ovunque oggi. È il formato alla base di screenshot, risorse di interfaccia, diagrammi, loghi e qualsiasi immagine in cui i pixel devono rimanere esattamente identici dopo salvataggi ripetuti. È più vecchio di Google, più vecchio dell'iPod, e resta la scelta predefinita quando la compressione lossless è fondamentale. Ma non è mai stato pensato come uno standard. È nato come una soluzione temporanea, non come uno standard.
La causa che ha forzato un nuovo formato
Nel gennaio 1995, Unisys annunciò che avrebbe fatto rispettare il suo brevetto di compressione LZW — il brevetto USA 4.558.302 — contro gli sviluppatori che usavano il formato GIF. Il brevetto copriva l'algoritmo di Lempel-Ziv-Welch, il metodo di compressione al cuore di ogni encoder e decoder GIF.
Nel 1995 il Web si basava sul GIF. Banner animati, loghi trasparenti, sfondi ripetuti — il GIF faceva tutto. Poi Unisys chiese i canoni di licenza. I produttori di software commerciale dovettero affrontare costi di licenza. I progetti open source erano minacciati a livello esistenziale. Il GNU Image Manipulation Program (GIMP) fu direttamente colpito. La comunità degli sviluppatori Web era furiosa.
Qualcosa doveva sostituire il GIF per le immagini statiche. I requisiti erano chiari: nessun brevetto, compressione migliore del GIF, supporto per i true color, e un canale alpha vero al posto della grossolana trasparenza a un solo colore del GIF. Doveva anche essere abbastanza semplice perché un singolo sviluppatore potesse implementare un decoder in un weekend.
Il 4 aprile 1995, Thomas Boutell pubblicò una proposta sul newsgroup Usenet comp.graphics. La chiamò PBF — Portable Bitmap Format. Il nome non attecchì. Nei mesi successivi, si formò una mailing list. I contributori includevano Tom Lane (capo dell'Independent JPEG Group), Lee Daniel Crocker, Alexander Lehmann, e decine di altri. Entro il 1º ottobre 1996, la specifica PNG fu congelata come RFC 2083. L'intero processo richiese circa diciotto mesi dall'idea allo standard. Per confronto, il JPEG impiegò sei anni.
Cosa esisteva prima del PNG
Nel 1995, le opzioni di formato immagine erano limitate e ognuna portava un peso:
| Formato | Compressione | Profondità colore | Trasparenza | Rischio brevetto | Uso tipico |
|---|---|---|---|---|---|
| GIF | LZW | max 256 colori | 1 bit, 1 colore | Sì (LZW) | Grafica web, animazioni |
| JPEG | DCT + Huffman | 24 bit true color | Nessuna | Base scaduta | Fotografie |
| BMP | Nessuna o RLE | Fino a 24 bit | Nessuna | No | Sfondi Windows |
| TIFF | LZW, PackBits, ecc. | Fino a 48 bit | Sì | LZW opzionale | Stampa, scansione |
| PCX | RLE | Fino a 24 bit | Nessuna | No | Giochi DOS, clipart d'epoca |
Il GIF dominava il Web ma era legalmente tossico. La sua palette di 256 colori andava bene per icone e cartoni, ma era inutile per le fotografie. La sua trasparenza era binaria: un pixel era o completamente opaco o completamente trasparente. Niente bordi morbidi, niente ombre.
Il JPEG gestiva le fotografie in modo brillante ma distruggeva i dati in modo irreversibile. Apri un JPEG, modificalo, salvalo di nuovo, e l'immagine si degradava. Il JPEG non aveva neanche la trasparenza. Per i designer web che avevano bisogno di un logo che galleggiasse su uno sfondo texture, il JPEG era inutile.
Il BMP e il PCX erano non compressi o a malapena compressi. Un BMP 640 × 480 nel 1995 pesava 900 KB. Su un modem 28,8 kbps, ci volevano più di quattro minuti per scaricarlo.
Il TIFF era potente e flessibile, ma la sua flessibilità era la sua maledizione. I file TIFF potevano usare una dozzina di schemi di compressione, spazi colore e profondità di bit diversi. Scrivere un decoder TIFF universale era un progetto da tesi di dottorato, non un hack da weekend.
Il PNG fu progettato per colpire un bersaglio stretto: sostituire il GIF per le immagini statiche, battere la sua compressione, aggiungere i true color e la vera trasparenza, e restare libero per sempre.
Come il PNG comprime davvero
La compressione PNG è una pipeline a due stadi. Nessuno dei due passaggi è di per sé particolarmente astuto. Insieme sono sorprendentemente efficaci.
Stadio 1: filtraggio
Prima di qualsiasi compressione, il PNG fa passare i dati grezzi dei pixel attraverso un filtro. Il filtro non comprime nulla. Riorganizza i dati in modo che lo stadio successivo possa comprimerli meglio.
Un'immagine è una griglia di byte. In una fotografia di un cielo sereno, i pixel adiacenti sono quasi identici. Ma il flusso di byte grezzi memorizza comunque 120, 121, 120, 122, 119 per ogni canale. Le differenze sono minuscole: +1, -1, +2, -3. Se si memorizzano le differenze invece dei valori assoluti, i numeri risultanti si raggruppano intorno allo zero. Questo raggruppamento è ideale per gli algoritmi di compressione.
Il PNG definisce cinque tipi di filtro per riga di scansione:
| Filtro | Nome | Cosa fa |
|---|---|---|
| 0 | None | Memorizza byte grezzi |
| 1 | Sub | Memorizza la differenza dal pixel precedente |
| 2 | Up | Memorizza la differenza dal pixel sopra |
| 3 | Average | Memorizza la differenza dalla media di Sub e Up |
| 4 | Paeth | Memorizza la differenza dal miglior predittore (Sub/Up/diagonale) |
L'encoder prova tutti e cinque i filtri per riga di scansione e sceglie quello che produce l'output più piccolo dopo lo stadio 2. Per questo un encoder PNG può essere lento: sta facendo una ricerca a forza bruta sulle combinazioni di filtri. Ma la decodifica è veloce — il tipo di filtro è memorizzato nel file, quindi il decoder applica semplicemente l'operazione inversa.
Stadio 2: DEFLATE
Dopo il filtraggio, i dati vengono compressi con DEFLATE, lo stesso algoritmo usato da gzip e dai file ZIP. DEFLATE è una combinazione di LZ77 (eliminazione di stringhe duplicate a finestra scorrevole) e codifica di Huffman (codici prefisso a lunghezza variabile per simboli frequenti).
Il risultato: uno screenshot o una grafica di interfaccia tipica occupa 3–5 volte meno spazio di un BMP non compresso. Una fotografia compressa come PNG è solitamente 5–10× più grande di un JPEG, ma ogni pixel è recuperabile. La compressione è lossless per costruzione: nessun dato viene scartato, vengono rimosse solo le ridondanze.
Per dare un'idea, uno screenshot 1920 × 1080 in RGB grezzo pesa 6,2 MB. Lo stesso screenshot come PNG scende tipicamente a 800 KB – 1,5 MB. La stessa immagine come JPEG qualità 90 pesa 300–500 KB, ma risalvarla dieci volte introdurrebbe artefatti visibili.
Le funzionalità che contavano
Il PNG non era solo un clone del GIF esente da brevetti. Aggiunse capacità per cui i designer web chiedevano a gran voce dal 1993.
True color: il PNG supporta RGB 24 bit (16,7 milioni di colori) e deep color 48 bit. Nessun limite di palette. Una fotografia PNG può visualizzare ogni colore che l'occhio umano può distinguere.
Canale alpha: il PNG supporta alpha 8 bit — 256 livelli di trasparenza per pixel. Un'ombra può sfumare dolcemente da opaca a trasparente. Un pulsante arrotondato può eseguire l'antialiasing su qualsiasi sfondo. Il GIF offriva trasparenza 1 bit: un colore era o completamente attivo o completamente disattivo. La differenza visiva è enorme.
Interlacciamento Adam7: il PNG può memorizzare i pixel in un ordine interlacciato a 7 passaggi. Un browser renderizza un'anteprima grezza dopo aver ricevuto 1/64 del file, poi la affina progressivamente. A differenza dell'interlacciamento riga per riga del GIF, Adam7 distribuisce i dettagli sull'intera immagine dal primo passaggio. Al terzo passaggio, l'immagine è riconoscibile. Al settimo, è perfetta.
Correzione gamma: il PNG memorizza un valore gamma nei suoi metadati. Un'immagine creata su un Mac (gamma 1,8) viene visualizzata correttamente su un PC Windows (gamma 2,2) senza correzione colore manuale. Questo era un problema reale negli anni '90, quando la coerenza tra piattaforme era rara.
Checksum CRC: ogni chunk PNG porta un checksum CRC-32. I download corrotti vengono rilevati immediatamente invece di produrre un'immagine semi-renderizzata.
Rilevare il PNG leggendo la firma del file
Non ti fidare dell'estensione .png. Leggi i primi otto byte e controlla la firma.
Layout esatto dei byte:
Bytes 0–7: Signature 89 50 4E 47 0D 0A 1A 0A
Bytes 8–11: Chunk length (big-endian uint32)
Bytes 12–15: Chunk type: "IHDR" (image header)
Bytes 16–19: Image width (big-endian uint32)
Bytes 20–23: Image height (big-endian uint32)
Byte 24: Bit depth
Byte 25: Color type
Byte 26: Compression method (always 0)
Byte 27: Filter method (always 0)
Byte 28: Interlace method (0 or 1)
TypeScript nel browser:
async function isPng(file: File): Promise<boolean> {
const buffer = await file.slice(0, 8).arrayBuffer()
const bytes = new Uint8Array(buffer)
const signature = [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]
return bytes.length === 8 && bytes.every((b, i) => b === signature[i])
}
Python
def is_png(path: str) -> bool:
with open(path, "rb") as f:
header = f.read(8)
return header == b"\x89PNG\r\n\x1a\n"
Opzione di più alto livello con la libreria standard:
import imghdr
if imghdr.what("image.png") == "png":
pass
O con Pillow:
from PIL import Image
try:
with Image.open("image.png") as img:
is_png = img.format == "PNG"
except Exception:
is_png = False
Go
func isPng(path string) bool {
f, err := os.Open(path)
if err != nil {
return false
}
defer f.Close()
buf := make([]byte, 8)
if _, err := f.Read(buf); err != nil {
return false
}
return bytes.Equal(buf, []byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a})
}
PHP
function isPng(string $path): bool {
$header = file_get_contents($path, false, null, 0, 8);
return $header === "\x89PNG\r\n\x1a\n";
}
Con fileinfo:
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file('image.png');
// image/png
ImageMagick CLI
magick identify -verbose image.png | grep "Format:"
# Format: PNG (Portable Network Graphics)
O semplicemente:
file image.png
# image.png: PNG image data, 1200 x 675, 8-bit/color RGBA, non-interlaced
I limiti del PNG
Il PNG non è perfetto. Le sue scelte di progettazione erano compromessi, e alcuni di quei compromessi ci costano ancora oggi.
Nessuna animazione integrata: il PNG Working Group rifiutò esplicitamente l'animazione. Volevano risolvere completamente il problema delle immagini statiche prima di aggiungere complessità. Il risultato: il GIF animato sopravvisse altri due decenni. L'APNG (Animated PNG) fu infine standardizzato nel 2004, ma il supporto browser rimase frammentario fino alla fine degli anni 2010. Anche oggi, i GIF animati dominano gli APNG.
Dimensioni di file grandi per le fotografie: una foto da 12 MP come PNG è tipicamente 15–25 MB. Come JPEG qualità 90, è 3–5 MB. La compressione lossless del PNG non può competere con la riduzione psicovisiva basata sulla DCT del JPEG. Per le fotografie, il PNG è lo strumento sbagliato.
Nessun supporto CMYK: il PNG è solo RGB. I flussi di lavoro di stampa che richiedono la separazione CMYK devono convertire il PNG in TIFF o JPEG. Questa fu una scelta deliberata — i progettisti si concentrarono sulla visualizzazione su schermo, non sulla stampa — ma limita l'utilità del PNG nell'editoria professionale.
Decodifica più lenta del JPEG: la decodifica PNG richiede filtraggio inverso per riga di scansione e decompressione DEFLATE. La decodifica JPEG è altamente parallelizzabile e pesantemente ottimizzata nell'hardware. Sui dispositivi mobili, un PNG grande può impiegare 2–3× più tempo per essere renderizzato rispetto a un JPEG di uguale risoluzione, ritardando il Largest Contentful Paint.
Nessuna qualità progressiva: a differenza di JPEG 2000 o JPEG XL, il PNG non può produrre un'anteprima di qualità inferiore da un file troncato. O hai l'intero file, o non hai nulla. L'interlacciamento Adam7 aiuta con le anteprime grezze, ma non riduce la dimensione totale del file.
Perché il PNG non ha mai sostituito il JPEG
Questo è il malinteso più comune sui formati immagine. Il PNG e il JPEG non hanno mai gareggiato per lo stesso lavoro.
Il JPEG è un compressore psicovisivo con perdita. Scarta dati che i tuoi occhi probabilmente non avrebbero notato. È stato progettato per fotografie a toni continui — immagini con gradienti uniformi, texture fine e illuminazione naturale. Per quel lavoro, il JPEG resta imbattibile sul rapporto dimensione-qualità dopo trentatré anni.
Il PNG è un compressore di dati lossless. Preserva ogni bit. È stato progettato per immagini a toni discreti — screenshot, elementi di interfaccia, diagrammi, loghi, sovrapposizioni di testo — dove i bordi netti e i colori esatti contano. Per quel lavoro, il PNG è lo standard.
I due formati si sono divisi il Web in territori distinti:
| Caso d'uso | Formato corretto | Perché |
|---|---|---|
| Fotografie | JPEG/AVIF | La compressione con perdita è 5–10× più piccola |
| Screenshot | PNG/WebP | Il lossless preserva la nitidezza del testo |
| Loghi con trasparenza | PNG/WebP | Canale alpha + bordi lossless |
| Icone di interfaccia | PNG/SVG | Dimensione ridotta, corrispondenza cromatica esatta |
| Visualizzazioni di dati scientifici | PNG | Nessun artefatto nelle legende a gradiente |
| Immagini pronte per la stampa | TIFF/JPEG XL | Supporto CMYK, alta profondità di bit |
Il PNG non ha mai cercato di sostituire il JPEG. Ha semplicemente trovato un altro lavoro.
Dove si trova il PNG oggi
Il Web Almanac 2025 stima la quota del PNG a circa il 22 % di tutte le immagini servite sul Web. È in calo rispetto al picco — WebP e AVIF stanno conquistando quote — ma il PNG resta il formato di ripiego che ogni browser, ogni editor di immagini e ogni sistema operativo può aprire senza esitazione.
WebP (Google, 2010) supporta sia modalità con perdita che lossless, più animazione e trasparenza. Un WebP lossless è tipicamente 20–30 % più piccolo di un PNG equivalente. Il supporto browser è universale dal 2020. Per i nuovi progetti, WebP lossless è la sostituzione pragmatica del PNG nella maggior parte dei casi.
AVIF (AOM, 2019) raggiunge una compressione ancora migliore, ma la sua modalità lossless è più lenta da codificare e decodificare rispetto al PNG. L'AVIF manca inoltre del pieno supporto browser per alcune funzionalità PNG avanzate come i canali a 16 bit e la correzione gamma integrata.
SVG domina lo spazio icone e loghi per la grafica vettoriale semplice, ma le grafiche complesse rasterizzate hanno ancora bisogno del PNG.
La realtà pratica: il PNG non sta scomparendo. È la scelta sicura predefinita, il formato in cui si esporta quando si deve garantire che il destinatario possa aprire il file. È il QWERTY dei formati immagine — non ottimale, ma universalmente compreso.
Il futuro del PNG
Il PNG è uno standard completato. La specifica non è cambiata in modo significativo dal 2003. Questa stabilità è un punto di forza, non un difetto. Puoi aprire un PNG creato nel 1997 in qualsiasi browser moderno e sarà renderizzato in modo identico.
Ma l'ecosistema intorno al PNG continua a evolversi:
L'APNG sta guadagnando terreno. Safari lo supporta dal 2014. Chrome e Firefox hanno seguito. Discord, Slack e Twitter renderizzano tutti gli APNG nativamente. Per brevi animazioni di interfaccia — indicatori di caricamento, emoji di reazione, indicatori di stato — l'APNG sta sostituendo il GIF animato con file più piccoli e migliore fedeltà cromatica.
Gli strumenti di ottimizzazione PNG continuano a migliorare. oxipng, pngcrush e zopfli possono ridurre un altro 10–30 % dalle dimensioni dei file PNG forzando con la forza bruta combinazioni di filtri e parametri DEFLATE migliori. Per i siti ad alto traffico, far passare ogni PNG attraverso oxipng è pratica standard.
Il PNG come contenitore: alcuni flussi di lavoro moderni incorporano profili colore ICC, metadati EXIF e persino dati XMP all'interno dei chunk PNG. Il PNG è diventato un formato di archiviazione leggero — non ricco come il TIFF, ma molto più portatile.
La prospettiva a lungo termine: il PNG coesisterà con WebP, AVIF e JPEG XL per anni. Riempie una nicchia che nessun altro formato possiede completamente: lossless, esente da brevetti, universalmente supportato, e abbastanza semplice che un singolo sviluppatore può scrivere un decoder dalla specifica in una settimana. Questa combinazione è difficile da spodestare.
La conclusione
Il PNG è nato perché gli sviluppatori erano stufi. Una causa per violazione di brevetto minacciava il Web aperto, e un gruppo di sviluppatori costruì un'alternativa nel loro tempo libero. Non intendevano creare uno standard che durasse trent'anni. Intendevano risolvere un problema: come mettere un logo trasparente su una pagina Web senza pagare diritti di licenza.
Il risultato era molto migliore di quanto chiunque si aspettasse. Il PNG ha offerto al Web grafica a true color, trasparenza morbida e un'integrità dei file robusta. Ha dimostrato che gli standard aperti, costruiti da volontari, potevano superare i formati proprietari sostenuti da grandi aziende.
Non è il formato più compatto. Non è il più veloce da decodificare. Non gestisce bene l'animazione, ed è inadatto per le fotografie. Ma quando devi essere certo che ogni pixel salvato sia esattamente quello che recupererai — il PNG resta lo strumento a cui ricorri.
Non tutte le immagini nascono come PNG. Se hai dei JPG che hanno bisogno di trasparenza o di editing senza perdite, puoi convertirli direttamente nel tuo browser — nessun software da installare, niente lascia il tuo dispositivo. JPG a PNG se ne occupa in locale. Per i progetti web dove conta la dimensione del file, JPG a WebP alleggerisce senza toccare la qualità. E quando ti servono icone favicon, JPG a ICO trasforma le foto in file ICO a diverse dimensioni.


