La nascita di WebP: come VP8 divenne formato immagine

Apri un file WebP in un editor esadecimale. I primi dodici byte:

52 49 46 46 ?? ?? ?? ?? 57 45 42 50

Questa è l'intestazione del container in stile RIFF/WAVE. 52 49 46 46 corrisponde a "RIFF" in ASCII. I successivi quattro byte rappresentano la dimensione del file in uint32 little-endian. 57 45 42 50 corrisponde a "WEBP". Un file WebP non è un flusso di bit grezzo. È un container, esattamente come l'audio WAV o il video AVI, costruito secondo la stessa specifica RIFF che Microsoft introdusse nel 1991. All'interno di quel container risiede un frame video VP8, riadattato per un'immagine statica. Questa scelta progettuale — usare un codec video per le foto — è l'elemento più importante da comprendere su WebP.

Google annunciò WebP il 30 settembre 2010. La proposta era semplice: stessa qualità visiva di JPEG, ma file più piccoli del 25-34%. Per PNG, la promessa era ancora più audace — il 26% in meno per immagini senza perdita. Su un web dove i byte delle immagini rappresentano circa la metà di tutti i dati trasferiti, questi numeri avrebbero dovuto bastare a innescare un'adozione di massa. Non bastarono.

L'acquisizione che creò WebP

WebP non nacque in un laboratorio di immagini. Nacque da un codec video.

Nel febbraio 2010, Google acquisì On2 Technologies per circa 124 milioni di dollari. On2 era un'azienda di compressione video con una lunga storia — i suoi codec alimentavano i video Flash, le chiamate video di Skype e lo streaming di AOL. Il loro prodotto di punta era VP8, un codec video progettato per competere con H.264 senza royalties sui brevetti.

Google rese VP8 open source nel maggio 2010 con il nome WebM, abbinandolo al codec audio Vorbis e al container Matroska. L'obiettivo era chiaro: costruire uno stack video libero da brevetti per sfidare il pool di licenze H.264 di MPEG-LA, che stava iniziando a richiedere royalties per lo streaming video sul web.

Ma Google aveva in mente anche un secondo caso d'uso. La compressione intra-fotogramma di VP8 — la compressione di un singolo frame video senza riferimento ad altri frame — era sostanzialmente un codec per immagini statiche. Le stesse modalità di predizione, la codifica per trasformazione e la codifica entropica che rendevano VP8 efficiente per il video funzionavano anche per le fotografie. Google estrasse la modalità intra-fotogramma, la incapsulò in un container RIFF e la chiamò WebP.

Il nome fu una scelta di marketing. "Web" perché era progettato per il web. "P" perché i formati immagine finiscono in P — JPEG, PNG, BMP, TIFF. Il risultato fu un formato che tecnicamente era un frame video che fingeva di essere una foto.

Perché costruire un nuovo formato?

Nel 2010, JPEG aveva diciotto anni e PNG ne aveva quattordici. Entrambi erano radicati. Perché scomodarsi?

Le limitazioni di JPEG erano reali e ben note:

• Nessuna trasparenza. Un pixel JPEG è completamente opaco o serve una maschera separata.
• Nessuna animazione. Il JPEG animato non esiste come standard.
• Solo con perdita. La specifica base di JPEG non ha modalità senza perdita. (JPEG-LS e JPEG 2000 esistono, ma nessuno è compatibile con il web.)
• Profondità colore di 8 bit per canale. Nessun supporto wide-gamut o HDR nella specifica base.
• Artefatti a blocchi a bassa qualità. La griglia DCT 8 x 8 è visibile con impostazioni di qualità inferiori a 75.

Le limitazioni di PNG erano altrettanto reali:

• Nessuna modalità con perdita. PNG è sempre senza perdita. Una foto da 12 MP in PNG pesa 15-25 MB.
• File grandi per le fotografie. La compressione DEFLATE di PNG non può competere con lo scarto psicovisuale basato su DCT.
• Nessuna animazione nella specifica base. APNG esiste ma ha impiegato anni a ottenere supporto nei browser.

Google vide uno spazio vuoto: un formato unico in grado di offrire compressione con perdita e senza perdita, trasparenza e animazione, tutto in file più piccoli degli incumbent. Questa era la proposta di WebP.

Come funziona WebP

WebP ha due formati interni fondamentalmente diversi: WebP con perdita (VP8 intra-fotogramma) e WebP senza perdita (un codec separato, anch'esso derivato dalla ricerca su VP8).

WebP con perdita: VP8 Intra

WebP con perdita memorizza un flusso di bit VP8 all'interno di un container RIFF. La pipeline di codifica è concettualmente simile a JPEG ma con differenze chiave:

L'intra prediction è il vantaggio più significativo. JPEG codifica ogni blocco 8 x 8 in modo indipendente. WebP predice ogni blocco 4 x 4 dai suoi vicini già codificati — sopra, a sinistra o entrambi — poi codifica solo l'errore di predizione. Per gradienti uniformi e grandi regioni piatte, l'errore è minimo e il rapporto di compressione migliora sensibilmente.

L'arithmetic coder è anche più efficiente dell'Huffman coding di JPEG — tipicamente un risparmio aggiuntivo del 5-10% per la stessa qualità.

I benchmark di Google del 2010 sostenevano:

La velocità di codifica era il costo nascosto. Produrre un file WebP richiedeva molta più CPU rispetto a JPEG. Per i fotografi che esportano centinaia di immagini, questo contava.

WebP senza perdita

WebP senza perdita utilizza un codec completamente diverso. Non è VP8. È un formato custom che combina:

• Codifica predittiva: 14 diverse modalità di predizione spaziale per pixel.
• Color cache: Una tabella hash dei colori recentemente visti per sfruttare la ripetizione locale.
• LZ77 back-references: Come il DEFLATE di PNG, ma con matching 2D spatial-aware.
• Ibrido Huffman + aritmetico: La codifica entropica si adatta alle statistiche locali.

Google sosteneva file più piccoli del 26% rispetto a PNG in media. In pratica, i risparmi variano notevolmente — le grafiche semplici con grandi regioni piatte vedono poco beneficio, mentre le foto con texture fini possono raggiungere una riduzione del 30-40%.

WebP esteso (VP8X)

Il chunk VP8X estende WebP con funzionalità aggiuntive:

• Canale alpha: Alpha a 8 bit codificato separatamente, compresso con il codificatore entropico di WebP senza perdita.
• Animazione: Frame multipli con metadati di temporizzazione, essenzialmente un video VP8 alleggerito.
• Metadati EXIF: Dati della fotocamera e geolocalizzazione.
• Metadati XMP: Istruzioni di elaborazione in stile Adobe.
• Profilo colore ICC: Gestione del colore wide-gamut e HDR.

Un file VP8X inizia con un'intestazione VP8X, seguita da flag che indicano quali estensioni sono presenti.

Il formato del file

WebP è un container RIFF. Comprendere il layout dei byte è semplice se si conosce RIFF.

Struttura del container RIFF

Bytes 0-3:   "RIFF" (0x52 0x49 0x46 0x46)
Bytes 4-7:   Dimensione file - 8 (little-endian uint32)
Bytes 8-11:  "WEBP" (0x57 0x45 0x42 0x50)
Bytes 12-15: Chunk FourCC — "VP8 ", "VP8L", o "VP8X"
Bytes 16-19: Dimensione chunk (little-endian uint32)
Bytes 20+:   Dati chunk

Intestazione estesa VP8X

Se il FourCC ai byte 12-15 è "VP8X" (0x56 0x50 0x38 0x58):

Bytes 20-23: Dimensione chunk = 10 (little-endian uint32)
Bytes 24:    Byte dei flag
             Bit 0: Animazione presente
             Bit 1: Metadati XMP presenti
             Bit 2: Metadati EXIF presenti
             Bit 3: Canale alpha presente
             Bit 4: Profilo ICC presente
             Bit 5-7: Riservati
Bytes 25-27: Larghezza canvas - 1 (little-endian uint24)
Bytes 28-30: Altezza canvas - 1 (little-endian uint24)

Le dimensioni del canvas sono memorizzate come larghezza - 1 e altezza - 1, quindi un'immagine 1200 x 675 memorizza 1199 e 674. La dimensione massima del canvas è 16.777.215 x 16.777.215 pixel.

Tipi di chunk

Rilevare WebP leggendo la firma del file

Non fidarti dell'estensione .webp. Leggi i primi 16 byte e analizza l'intestazione RIFF.

Layout esatto dei byte di un WebP con perdita semplice:

Bytes 0-3:   "RIFF"
Bytes 4-7:   Dimensione file (little-endian uint32)
Bytes 8-11:  "WEBP"
Bytes 12-15: "VP8 " (lossy) o "VP8L" (lossless) o "VP8X" (esteso)

TypeScript nel browser:

interface WebPInfo {
  valid: boolean
  type: "lossy" | "lossless" | "extended" | "unknown"
  width?: number
  height?: number
  hasAlpha?: boolean
  isAnimated?: boolean
}

async function inspectWebP(file: File): Promise<WebPInfo> {
  const buffer = await file.slice(0, 30).arrayBuffer()
  const bytes = new Uint8Array(buffer)

  if (bytes.length < 12) return { valid: false, type: "unknown" }

  const riff = String.fromCharCode(...bytes.slice(0, 4))
  const webp = String.fromCharCode(...bytes.slice(8, 12))
  if (riff !== "RIFF" || webp !== "WEBP") {
    return { valid: false, type: "unknown" }
  }

  const type = String.fromCharCode(...bytes.slice(12, 16))

  if (type === "VP8 ") {
    // Lossy: larghezza/altezza ai byte 26-29
    const w = bytes[26] | (bytes[27] << 8)
    const h = bytes[28] | (bytes[29] << 8)
    return { valid: true, type: "lossy", width: w, height: h, hasAlpha: false }
  }

  if (type === "VP8L") {
    // Lossless: dimensioni impacchettate nei bit dei byte 21-24
    const bits =
      bytes[21] | (bytes[22] << 8) | (bytes[23] << 16) | (bytes[24] << 24)
    const w = (bits & 0x3fff) + 1
    const h = ((bits >> 14) & 0x3fff) + 1
    const alpha = ((bits >> 28) & 0x01) !== 0
    return {
      valid: true,
      type: "lossless",
      width: w,
      height: h,
      hasAlpha: alpha,
    }
  }

  if (type === "VP8X") {
    const flags = bytes[20]
    const w = (bytes[24] | (bytes[25] << 8) | (bytes[26] << 16)) + 1
    const h = (bytes[27] | (bytes[28] << 8) | (bytes[29] << 16)) + 1
    return {
      valid: true,
      type: "extended",
      width: w,
      height: h,
      hasAlpha: (flags & 0x10) !== 0,
      isAnimated: (flags & 0x02) !== 0,
    }
  }

  return { valid: false, type: "unknown" }
}

Python

import struct
from typing import TypedDict

class WebPInfo(TypedDict):
    valid: bool
    type: str
    width: int | None
    height: int | None
    has_alpha: bool | None
    is_animated: bool | None

def inspect_webp(path: str) -> WebPInfo:
    with open(path, "rb") as f:
        header = f.read(30)

    if len(header) < 12:
        return {"valid": False, "type": "unknown"}

    if header[:4] != b"RIFF" or header[8:12] != b"WEBP":
        return {"valid": False, "type": "unknown"}

    chunk_type = header[12:16]

    if chunk_type == b"VP8 ":
        w, h = struct.unpack("<HH", header[26:30])
        return {"valid": True, "type": "lossy", "width": w, "height": h,
                "has_alpha": False, "is_animated": None}

    if chunk_type == b"VP8L":
        bits = struct.unpack("<I", header[21:25])[0]
        w = (bits & 0x3FFF) + 1
        h = ((bits >> 14) & 0x3FFF) + 1
        alpha = ((bits >> 28) & 0x01) != 0
        return {"valid": True, "type": "lossless", "width": w, "height": h,
                "has_alpha": alpha, "is_animated": None}

    if chunk_type == b"VP8X":
        flags = header[20]
        w = struct.unpack("<I", header[24:27] + b"\x00")[0] + 1
        h = struct.unpack("<I", header[27:30] + b"\x00")[0] + 1
        return {"valid": True, "type": "extended", "width": w, "height": h,
                "has_alpha": bool(flags & 0x10), "is_animated": bool(flags & 0x02)}

    return {"valid": False, "type": "unknown"}

Opzione di più alto livello con Pillow:

from PIL import Image

with Image.open("image.webp") as img:
    print(img.format)      # WEBP
    print(img.mode)        # RGB o RGBA
    print(img.size)        # (larghezza, altezza)
    print(img.is_animated) # True se animata

Oppure con la libreria webp:

import webp

info = webp.WebPInfo("image.webp")
print(info.width, info.height, info.has_alpha)

Go

package main

import (
	"encoding/binary"
	"fmt"
	"os"
)

type WebPInfo struct {
	Valid       bool
	Type        string
	Width       int
	Height      int
	HasAlpha    bool
	IsAnimated  bool
}

func inspectWebP(path string) (WebPInfo, error) {
	f, err := os.Open(path)
	if err != nil {
		return WebPInfo{}, err
	}
	defer f.Close()

	buf := make([]byte, 30)
	if _, err := f.Read(buf); err != nil {
		return WebPInfo{}, err
	}

	if string(buf[:4]) != "RIFF" || string(buf[8:12]) != "WEBP" {
		return WebPInfo{Valid: false, Type: "unknown"}, nil
	}

	typeStr := string(buf[12:16])
	switch typeStr {
	case "VP8 ":
		w := int(binary.LittleEndian.Uint16(buf[26:28]))
		h := int(binary.LittleEndian.Uint16(buf[28:30]))
		return WebPInfo{Valid: true, Type: "lossy", Width: w, Height: h, HasAlpha: false}, nil
	case "VP8L":
		bits := binary.LittleEndian.Uint32(buf[21:25])
		w := int(bits&0x3FFF) + 1
		h := int((bits>>14)&0x3FFF) + 1
		alpha := ((bits >> 28) & 0x01) != 0
		return WebPInfo{Valid: true, Type: "lossless", Width: w, Height: h, HasAlpha: alpha}, nil
	case "VP8X":
		flags := buf[20]
		w := int(binary.LittleEndian.Uint32(append(buf[24:27], 0))) + 1
		h := int(binary.LittleEndian.Uint32(append(buf[27:30], 0))) + 1
		return WebPInfo{
			Valid: true, Type: "extended", Width: w, Height: h,
			HasAlpha: (flags & 0x10) != 0, IsAnimated: (flags & 0x02) != 0,
		}, nil
	}

	return WebPInfo{Valid: false, Type: "unknown"}, nil
}

PHP

function inspectWebP(string $path): array {
    $header = file_get_contents($path, false, null, 0, 30);
    if (strlen($header) < 12) {
        return ["valid" => false, "type" => "unknown"];
    }

    if (substr($header, 0, 4) !== "RIFF" || substr($header, 8, 4) !== "WEBP") {
        return ["valid" => false, "type" => "unknown"];
    }

    $type = substr($header, 12, 4);

    if ($type === "VP8 ") {
        $w = unpack("v", substr($header, 26, 2))[1];
        $h = unpack("v", substr($header, 28, 2))[1];
        return ["valid" => true, "type" => "lossy", "width" => $w, "height" => $h, "has_alpha" => false];
    }

    if ($type === "VP8L") {
        $bits = unpack("V", substr($header, 21, 4))[1];
        $w = ($bits & 0x3FFF) + 1;
        $h = (($bits >> 14) & 0x3FFF) + 1;
        $alpha = (($bits >> 28) & 0x01) !== 0;
        return ["valid" => true, "type" => "lossless", "width" => $w, "height" => $h, "has_alpha" => $alpha];
    }

    if ($type === "VP8X") {
        $flags = ord($header[20]);
        $w = unpack("V", substr($header, 24, 3) . "\x00")[1] + 1;
        $h = unpack("V", substr($header, 27, 3) . "\x00")[1] + 1;
        return [
            "valid" => true, "type" => "extended",
            "width" => $w, "height" => $h,
            "has_alpha" => (bool)($flags & 0x10),
            "is_animated" => (bool)($flags & 0x02),
        ];
    }

    return ["valid" => false, "type" => "unknown"];
}

Con fileinfo:

$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file('image.webp');
// image/webp

ImageMagick CLI

magick identify -verbose image.webp | grep "Format:"
# Format: WEBP (WebP Image Format)

Estrazione completa dei metadati:

magick identify -verbose image.webp

Questo restituisce larghezza, altezza, profondità colore, presenza di alpha, tipo di compressione e informazioni sul profilo ICC.

Oppure semplicemente:

file image.webp
# image.webp: RIFF (little-endian) data, Web/P image

I punti di forza

WebP è tecnicamente impressionante in specifiche dimensioni:

File più piccoli: Sul corpus di riferimento di Google, WebP con perdita ha mediamente raggiunto file più piccoli del 25-34% rispetto a JPEG allo stesso SSIM. WebP senza perdita ha mediamente raggiunto file più piccoli del 26% rispetto a PNG. Per siti ad alto traffico, questi risparmi si traducono direttamente in costi di banda e caricamenti pagina più veloci.

Consolidamento delle funzionalità: Un formato unico sostituisce sia JPEG che PNG per la maggior parte dei casi d'uso. Modalità con perdita per le foto, modalità senza perdita per le grafiche, canale alpha per la trasparenza, animazione per sequenze brevi. Uno sviluppatore web deve conoscere un formato invece di tre.

Decode nativo nel browser: Chrome, Firefox, Safari e Edge integrano tutti decoder WebP accelerati via hardware o altamente ottimizzati in software. La velocità di decodifica è comparabile a JPEG su desktop e entro il 10-20% su mobile.

Decodifica progressiva: WebP supporta la visualizzazione incrementale man mano che i dati arrivano, simile alla modalità progressive di JPEG. Per connessioni lente, un'immagine riconoscibile appare dopo aver ricevuto circa il 30% del file.

Animazione: I file WebP animati sono tipicamente più piccoli del 60-80% rispetto alle GIF animate a qualità visiva equivalente, con colore a 24 bit e alpha a 8 bit per frame.

I punti deboli

I problemi di WebP non sono tecnici. Sono ecologici.

Velocità di codifica: Nel 2010, la codifica WebP era circa 8 volte più lenta di libjpeg. Il divario si è ridotto — libwebp nel 2026 è circa 2-3 volte più lento di libjpeg-turbo — ma conta ancora per i flussi di lavoro batch. Un fotografo che esporta 1.000 immagini aspetterà sensibilmente di più.

Nessun supporto a 16 bit o HDR: WebP è rigorosamente a 8 bit per canale. Per fotografia wide-gamut, imaging medico o contenuti HDR, WebP è inutilizzabile. HEIC, AVIF e JPEG XL supportano tutti profondità di bit superiori.

Nessuna ricompressione senza perdita di JPEG: JPEG XL può prendere un JPEG esistente e ricomprimerlo senza perdita per un risparmio di circa il 20%. WebP non può. Convertire un JPEG in WebP richiede una ricodifica completa, che introduce generation loss.

Lacune nel tooling: Photoshop non ha supportato WebP nativamente fino al 2022. Il supporto WebP di ImageMagick richiedeva la compilazione di un plugin libwebp, che molte distribuzioni omettevano di default. Molti content management system generano ancora JPEG/PNG di default.

La nube brevettuale su VP8: Google ha rilasciato VP8 con una promessa di indennizzo sui brevetti, ma il panorama brevettuale del codec non è mai stato così pulito come quello di PNG o JPEG. Alcune organizzazioni hanno evitato WebP specificamente perché non si fidavano che lo scudo legale di Google reggesse in tribunale.

Perché il formato "inferiore" ha vinto

JPEG ha trentaquattro anni. Non ha trasparenza, non ha animazione, non ha modalità senza perdita e artefatti visibili a qualità 75. WebP lo batte su quasi ogni metrica. Eppure il Web Almanac 2025 attribuisce a JPEG circa il 46% di tutte le immagini web contro il 19% di WebP.

Il motivo non è tecnico. Sono gli effetti di rete e i costi di cambiamento.

JPEG è il QWERTY dei formati immagine. Ogni fotocamera salva JPEG di default. Ogni telefono visualizza JPEG nativamente. Ogni stampante accetta JPEG. Ogni social network, CMS, CDN e client email gestisce JPEG senza plugin, codec o conversione. Il formato è così universale che "immagine" e "JPEG" sono funzionalmente sinonimi per la maggior parte degli utenti.

La curva di adozione di WebP racconta la storia:

Chrome ha spinto WebP aggressivamente perché Google controllava sia il browser che il formato. Facebook lo ha adottato perché risparmiava petabyte di banda. Ma la coda lunga del web — blog WordPress, piccoli siti e-commerce, deployment enterprise di CMS, newsletter email — si è mossa lentamente o per nulla.

Il punto di fallimento critico è stato l'ecosistema Apple. Gli iPhone salvano HEIC di default, non WebP. macOS Preview non ha supportato WebP fino a macOS 11 Big Sur (2020). Il share sheet di iOS non offriva esportazione WebP. Per fotografi, designer e creator di social media che lavorano principalmente su dispositivi Apple, WebP era invisibile.

Nel frattempo, AVIF è arrivato nel 2019 con compressione migliore di WebP e licenze royalty-free dall'Alliance for Open Media. Chrome, Firefox e Safari integrano tutti AVIF. Cloudflare e Cloudinary servono AVIF automaticamente. WebP è diventato un gradino intermedio — meglio di JPEG, ma già superato dalla generazione successiva.

La posizione di WebP oggi

WebP non è un fallimento. È un successo parziale.

Per gli sviluppatori web che costruiscono nuovi progetti nel 2026, WebP è la scelta pragmatica di default per immagini che necessitano di trasparenza o animazione. È più piccolo di PNG per le grafiche senza perdita e più piccolo di JPEG per le fotografie. Il supporto browser è universale. Il tooling di codifica è maturo.

Ma WebP non ha sostituito JPEG. Si è ritagliato una nicchia accanto a esso — la stessa nicchia che PNG già occupava, solo con file più piccoli. La visione di "un formato per tutte le immagini" non si è materializzata.

La realtà pratica per il 2026:

Il vero lascito di WebP è aver dimostrato che il web può adottare nuovi formati immagine quando un grande vendor di browser spinge con sufficiente forza. Ha spianato la strada ad AVIF. Ha costretto Apple a supportare nativamente formati diversi da JPEG/PNG. Ha dimostrato che trasparenza e animazione meritano di stare in un singolo container.

Ma ha anche dimostrato che la superiorità tecnica non basta. Ubiquità, inerzia e allineamento dell'ecosistema contano più dei rapporti di compressione. JPEG sopravvivrà a WebP non perché è migliore, ma perché è già ovunque.

La conclusione

WebP è stato costruito a partire da un codec video per risolvere un problema di banda. Ha risolto quel problema — per Google, per Facebook, per ogni sito disposto a convertire la propria pipeline immagini. La compressione è reale, le funzionalità sono utili e il supporto browser è completo.

Ma il web non cambia formato perché un white paper dice che quello nuovo è più piccolo del 25%. Cambia quando il nuovo formato è più facile da usare di quello vecchio, o quando quello vecchio fallisce così gravemente che la migrazione è inevitabile. JPEG non ha fallito abbastanza gravemente. WebP non era abbastanza facile. E quando WebP è diventato facile, AVIF era già arrivato con un numero più grande sul foglio delle specifiche.

WebP è il Betamax dei formati immagine — tecnicamente solido, ben supportato e alla fine superato da qualcosa arrivato poco dopo con marketing migliore e appoggio più ampio. Non scomparirà. Coesisterà con JPEG, PNG, AVIF e qualunque cosa verrà dopo, svolgendo lo stesso ruolo che PNG svolge oggi: il fallback sicuro e capace che funziona ovunque.

Se hai file PNG che devono occupare meno spazio sul web, PNG to WebP li converte localmente nel tuo browser — nessun upload, nessuna elaborazione server. Per JPEG che necessitano di trasparenza o animazione, JPG to WebP gestisce la conversione con controllo qualità. E quando ti serve il fallback universale, WebP to PNG e WebP to JPG riportano i file WebP a formati che si aprono in ogni visualizzatore.