Naissance de WebP : comment VP8 est devenu format d'image

Ouvrez un fichier WebP dans un éditeur hexadécimal. Les douze premiers octets :

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

C'est un en-tête de conteneur de style RIFF/WAVE. 52 49 46 46 écrit "RIFF" en ASCII. Les quatre octets suivants sont la taille du fichier en uint32 little-endian. 57 45 42 50 écrit "WEBP". Un fichier WebP n'est pas un flux binaire brut. C'est un conteneur, tout comme l'audio WAV ou la vidéo AVI, construit à partir de la même spécification RIFF que Microsoft a introduite en 1991. À l'intérieur de ce conteneur se trouve une frame vidéo VP8, réutilisée pour une image fixe. Ce choix de conception — utiliser un codec vidéo pour des photos — est la chose la plus importante à comprendre à propos de WebP.

Google a annoncé WebP le 30 septembre 2010. L'argument était simple : même qualité visuelle que JPEG, mais 25-34% plus petit. Pour PNG, l'affirmation était encore plus audacieuse — 26% plus petit pour les images sans perte. Sur un web où les octets d'image représentent environ la moitié de toutes les données transférées, ces chiffres auraient dû suffire à déclencher une adoption massive. Ils ne l'ont pas fait.

L'acquisition qui a créé WebP

WebP ne vient pas d'un laboratoire d'images. Il vient d'un codec vidéo.

En février 2010, Google a acquis On2 Technologies pour environ 124 millions de dollars. On2 était une entreprise de compression vidéo avec une longue histoire — leurs codecs alimentaient la vidéo Flash, les appels vidéo Skype et le streaming AOL. Leur produit phare était VP8, un codec vidéo conçu pour concurrencer H.264 sans redevances de brevet.

Google a rendu VP8 open source en mai 2010 sous le nom WebM, en le regroupant avec le codec audio Vorbis et le conteneur Matroska. L'objectif était clair : construire une stack vidéo exempte de brevets pour défier le pool de licences H.264 du MPEG-LA, qui commençait à exiger des redevances pour le streaming vidéo sur le web.

Mais Google avait un deuxième cas d'usage en tête. La compression intra-image de VP8 — la compression d'une seule frame vidéo sans référence aux autres frames — était essentiellement un codec d'image fixe. Les mêmes modes de prédiction, le codage par transformation et le codage entropique qui rendaient VP8 efficace pour la vidéo fonctionnaient aussi pour les photographies. Google a extrait le mode intra-image, l'a enveloppé dans un conteneur RIFF et l'a appelé WebP.

Le nom était un choix marketing. « Web » parce que c'était conçu pour le web. « P » parce que les formats d'image se terminent par P — JPEG, PNG, BMP, TIFF. Le résultat était un format qui était techniquement une frame vidéo faisant semblant d'être une photo.

Pourquoi créer un nouveau format du tout ?

En 2010, JPEG avait dix-huit ans et PNG en avait quatorze. Tous deux étaient ancrés. Pourquoi s'embêter ?

Les limitations de JPEG étaient réelles et bien connues :

• Pas de transparence. Un pixel JPEG est soit totalement opaque, soit vous avez besoin d'un masque séparé.
• Pas d'animation. Le JPEG animé n'existe pas en tant que standard.
• Avec perte uniquement. La spécification de base de JPEG n'a pas de mode sans perte. (JPEG-LS et JPEG 2000 existent, mais aucun n'est compatible avec le web.)
• Profondeur de couleur de 8 bits par canal. Pas de support wide-gamut ou HDR dans la spécification de base.
• Artifacts de blocage à faible qualité. La grille DCT de 8 x 8 est visible à des réglages de qualité inférieurs à 75.

Les limitations de PNG étaient tout aussi réelles :

• Pas de mode avec perte. PNG est toujours sans perte. Une photographie de 12 MP en PNG fait 15-25 Mo.
• Fichiers volumineux pour les photographies. La compression DEFLATE de PNG ne peut pas rivaliser avec le discard psycho-visuel basé sur DCT.
• Pas d'animation dans la spécification de base. APNG existe mais a mis des années à obtenir le support des navigateurs.

Google a identifié une lacune : un format unique capable de faire de la compression avec perte et sans perte, de la transparence et de l'animation, le tout dans des fichiers plus petits que les formats en place. C'était l'argument de vente de WebP.

Comment WebP fonctionne réellement

WebP possède deux formats internes fondamentalement différents : WebP avec perte (VP8 intra-image) et WebP sans perte (un codec séparé, également dérivé de la recherche sur VP8).

WebP avec perte : VP8 Intra

WebP avec perte stocke un flux binaire VP8 à l'intérieur d'un conteneur RIFF. Le pipeline d'encodage est conceptuellement similaire à JPEG mais avec des différences clés :

L'intra prediction est le plus grand gain. JPEG encode chaque bloc de 8 x 8 indépendamment. WebP prédit chaque bloc de 4 x 4 à partir de ses voisins déjà encodés — en haut, à gauche, ou les deux — puis n'encode que l'erreur de prédiction. Pour les dégradés lisses et les grandes zones plates, l'erreur est minuscule, et le taux de compression s'améliore significativement.

Le codeur arithmétique est également plus efficace que le codage Huffman de JPEG — typiquement 5-10% d'économies supplémentaires pour la même qualité.

Les benchmarks de Google eux-mêmes en 2010 affirmaient :

La vitesse d'encodage était le coût caché. Produire un fichier WebP nécessitait significativement plus de CPU que JPEG. Pour les photographes exportant des centaines d'images, cela comptait.

WebP sans perte

WebP sans perte utilise un codec complètement différent. Ce n'est pas VP8. C'est un format personnalisé combinant :

• Codage prédictif : 14 modes de prédiction spatiale différents par pixel.
• Color cache : une table de hachage des couleurs récemment vues pour exploiter la répétition locale.
• LZ77 back-references : comme le DEFLATE de PNG, mais avec une correspondance 2D spatialement consciente.
• Hybride Huffman + arithmétique : le codage entropique s'adapte aux statistiques locales.

Google affirmait des fichiers 26% plus petits que PNG en moyenne. En pratique, les économies varient énormément — les graphiques simples avec de grandes zones plates voient peu de bénéfice, tandis que les photographies avec une texture fine peuvent voir une réduction de 30-40%.

WebP étendu (VP8X)

Le chunk VP8X étend WebP avec des fonctionnalités supplémentaires :

• Canal alpha : alpha 8 bits encodé séparément, compressé avec le codeur entropique de WebP sans perte.
• Animation : frames multiples avec métadonnées de timing, essentiellement une vidéo VP8 allégée.
• Métadonnées EXIF : données de caméra et de géolocalisation.
• Métadonnées XMP : instructions de traitement de style Adobe.
• Profil de couleur ICC : gestion des couleurs wide-gamut et HDR.

Un fichier VP8X commence par un en-tête de chunk VP8X, suivi de flags qui indiquent quelles extensions sont présentes.

Le format de fichier

WebP est un conteneur RIFF. Comprendre la disposition des octets est simple si vous connaissez RIFF.

Structure du conteneur RIFF

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

En-tête étendu VP8X

Si le FourCC aux octets 12-15 est "VP8X" (0x56 0x50 0x38 0x58) :

Bytes 20-23: Chunk size = 10 (little-endian uint32)
Bytes 24:    Flags byte
             Bit 0: Animation present
             Bit 1: XMP metadata present
             Bit 2: EXIF metadata present
             Bit 3: Alpha channel present
             Bit 4: ICC profile present
             Bits 5-7: Reserved
Bytes 25-27: Canvas width - 1 (little-endian uint24)
Bytes 28-30: Canvas height - 1 (little-endian uint24)

Les dimensions du canvas sont stockées sous la forme width - 1 et height - 1, donc une image de 1200 x 675 stocke 1199 et 674. La taille maximale du canvas est de 16 777 215 x 16 777 215 pixels.

Types de chunks

Détecter WebP en lisant la signature de fichier

Ne faites pas confiance à l'extension .webp. Lisez les 16 premiers octets et analysez le header RIFF.

Disposition exacte des octets d'un WebP avec perte simple :

Bytes 0-3:   "RIFF"
Bytes 4-7:   File size (little-endian uint32)
Bytes 8-11:  "WEBP"
Bytes 12-15: "VP8 " (lossy) or "VP8L" (lossless) or "VP8X" (extended)

TypeScript dans le navigateur :

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: width/height at bytes 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: dimensions packed in bits of bytes 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"}

Option de plus haut niveau avec Pillow :

from PIL import Image

with Image.open("image.webp") as img:
    print(img.format)      # WEBP
    print(img.mode)        # RGB or RGBA
    print(img.size)        # (width, height)
    print(img.is_animated) # True if animated

Ou avec la bibliothèque 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"];
}

Avec fileinfo :

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

Ligne de commande ImageMagick

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

Extraction complète des métadonnées :

magick identify -verbose image.webp

Cela affiche la largeur, la hauteur, la profondeur de couleur, la présence d'alpha, le type de compression et les informations du profil ICC.

Ou simplement :

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

Les forces

WebP est techniquement impressionnant dans des dimensions spécifiques :

Fichiers plus petits : sur le corpus de référence de Google, WebP avec perte était en moyenne 25-34% plus petit que JPEG au même SSIM. WebP sans perte était en moyenne 26% plus petit que PNG. Pour les sites à fort trafic, ces économies se traduisent directement par des coûts de bande passante réduits et des chargements de page plus rapides.

Consolidation des fonctionnalités : un format remplace à la fois JPEG et PNG pour la plupart des cas d'usage. Le mode avec perte pour les photos, le mode sans perte pour les graphiques, le canal alpha pour la transparence, l'animation pour les courtes séquences. Un développeur web n'a besoin de connaître qu'un format au lieu de trois.

Décodage natif dans le navigateur : Chrome, Firefox, Safari et Edge intègrent tous des décodeurs WebP accélérés par matériel ou hautement optimisés en logiciel. La vitesse de décodage est comparable à JPEG sur desktop et dans une marge de 10-20% sur mobile.

Décodage progressif : WebP supporte l'affichage incrémental à mesure que les données arrivent, de manière similaire au mode progressive de JPEG. Pour les connexions lentes, une image reconnaissable apparaît après réception d'environ 30% du fichier.

Animation : les fichiers WebP animés sont typiquement 60-80% plus petits que les GIFs animés à qualité visuelle équivalente, avec une couleur 24 bits complète et un alpha 8 bits par frame.

Les faiblesses

Les problèmes de WebP ne sont pas techniques. Ils sont écologiques.

Vitesse d'encodage : en 2010, l'encodage WebP était environ 8 fois plus lent que libjpeg. L'écart s'est réduit — libwebp en 2026 est environ 2-3 fois plus lent que libjpeg-turbo — mais cela compte toujours pour les workflows par lots. Un photographe exportant 1 000 images attendra sensiblement plus longtemps.

Pas de support 16 bits ou HDR : WebP est strictement 8 bits par canal. Pour la photographie wide-gamut, l'imagerie médicale ou le contenu HDR, WebP est inutilisable. HEIC, AVIF et JPEG XL supportent tous des profondeurs de bits supérieures.

Pas de recompression JPEG sans perte : JPEG XL peut prendre un JPEG existant et le recompresser sans perte pour environ 20% d'économies. WebP ne le peut pas. Convertir un JPEG en WebP nécessite un ré-encodage complet, ce qui introduit une perte de génération.

Lacunes en matière d'outils : Photoshop n'a pas supporté WebP nativement avant 2022. Le support WebP d'ImageMagick nécessitait une compilation de plugin libwebp, que de nombreuses distributions omettaient par défaut. De nombreux systèmes de gestion de contenu génèrent encore JPEG/PNG par défaut.

Le nuage de brevets VP8 : Google a sorti VP8 avec une promesse d'indemnisation de brevets, mais le paysage des brevets du codec n'a jamais été aussi clair que celui de PNG ou JPEG. Certaines organisations ont évité WebP spécifiquement parce qu'elles ne faisaient pas confiance au bouclier juridique de Google pour résister devant les tribunaux.

Pourquoi le format « inférieur » a gagné

JPEG a trente-quatre ans. Il n'a pas de transparence, pas d'animation, pas de mode sans perte, et des artifacts visibles à la qualité 75. WebP le bat sur presque toutes les métriques. Pourtant, le Web Almanac 2025 place JPEG à environ 46% de toutes les images web contre 19% pour WebP.

La raison n'est pas technique. C'est les effets de réseau et les coûts de changement.

JPEG est le QWERTY des formats d'image. Chaque appareil photo enregistre JPEG par défaut. Chaque téléphone affiche JPEG nativement. Chaque imprimante accepte JPEG. Chaque réseau social, CMS, CDN et client de messagerie gère JPEG sans plugin, codec ou conversion. Le format est si universel que « image » et « JPEG » sont fonctionnellement synonymes pour la plupart des utilisateurs.

La courbe d'adoption de WebP raconte l'histoire :

Chrome a poussé WebP agressivement parce que Google contrôlait à la fois le navigateur et le format. Facebook l'a adopté parce que cela économisait des pétaoctets de bande passante. Mais la longue traîne du web — les blogs WordPress, les petits sites e-commerce, les déploiements de CMS d'entreprise, les newsletters par email — a avancé lentement ou pas du tout.

Le point d'échec critique était l'écosystème d'Apple. Les iPhones enregistraient HEIC par défaut, pas WebP. macOS Preview ne supportait pas WebP avant macOS 11 Big Sur (2020). La feuille de partage iOS n'offrait pas d'export WebP. Pour les photographes, designers et créateurs de contenu sur les réseaux sociaux travaillant principalement sur des appareils Apple, WebP était invisible.

Pendant ce temps, AVIF est arrivé en 2019 avec une meilleure compression que WebP et une licence exempte de redevances de l'Alliance for Open Media. Chrome, Firefox et Safari intègrent tous AVIF. Cloudflare et Cloudinary servent AVIF automatiquement. WebP est devenu une étape intermédiaire — meilleur que JPEG, mais déjà dépassé par la génération suivante.

Où en est WebP aujourd'hui

WebP n'est pas un échec. C'est un succès partiel.

Pour les développeurs web construisant de nouveaux projets en 2026, WebP est la valeur par défaut pragmatique pour les images nécessitant de la transparence ou de l'animation. Il est plus petit que PNG pour les graphiques sans perte et plus petit que JPEG pour les photographies. Le support des navigateurs est universel. Les outils d'encodage sont matures.

Mais WebP n'a pas remplacé JPEG. Il s'est taillé une niche à côté — la même niche que PNG occupait déjà, simplement avec des fichiers plus petits. La vision d'un « format unique pour toutes les images » ne s'est pas concrétisée.

La réalité pratique pour 2026 :

Le véritable héritage de WebP est de prouver que le web peut adopter de nouveaux formats d'image quand un éditeur de navigateur majeur pousse assez fort. Il a ouvert la voie à AVIF. Il a forcé Apple à supporter nativement les formats non-JPEG/PNG. Il a montré que la transparence et l'animation ont leur place dans un seul conteneur.

Mais il a aussi prouvé que la supériorité technique ne suffit pas. L'ubiquité, l'inertie et l'alignement de l'écosystème comptent plus que les taux de compression. JPEG survivra à WebP non pas parce qu'il est meilleur, mais parce qu'il est déjà partout.

Le fin mot de l'histoire

WebP a été construit à partir d'un codec vidéo pour résoudre un problème de bande passante. Il a résolu ce problème — pour Google, pour Facebook, pour tout site prêt à convertir son pipeline d'images. La compression est réelle, les fonctionnalités sont utiles, et le support des navigateurs est complet.

Mais le web ne change pas de format parce qu'un livre blanc dit que le nouveau est 25% plus petit. Il change quand le nouveau format est plus facile à utiliser que l'ancien, ou quand l'ancien échoue si mal que la migration est inévitable. JPEG n'a pas assez mal échoué. WebP n'était pas assez facile. Et au moment où WebP est devenu facile, AVIF était déjà arrivé avec un chiffre plus élevé sur la fiche technique.

WebP est le Betamax des formats d'image — techniquement solide, bien supporté, et finalement dépassé par quelque chose qui est arrivé un peu plus tard avec un meilleur marketing et un soutien plus large. Il ne disparaîtra pas. Il coexistera avec JPEG, PNG, AVIF, et tout ce qui viendra ensuite, jouant le même rôle que PNG joue aujourd'hui : le fallback sûr et capable qui fonctionne partout.

Si vous avez des fichiers PNG qui ont besoin d'empreintes plus petites pour le web, PNG vers WebP les convertit localement dans votre navigateur — pas d'uploads, pas de traitement serveur. Pour des JPEGs qui ont besoin de transparence ou d'animation, JPG vers WebP gère la conversion avec contrôle de qualité. Et quand vous avez besoin du fallback universel, WebP vers PNG et WebP vers JPG ramènent les fichiers WebP vers des formats qui s'ouvrent dans chaque visionneuse.