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

On reconnaît un en-tête de conteneur RIFF/WAVE. 52 49 46 46 écrit "RIFF" en ASCII. Les quatre octets suivants donnent 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, comme l'audio WAV ou la vidéo AVI, construit à partir de la spécification RIFF que Microsoft a introduite en 1991. À l'intérieur 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, explique beaucoup du fonctionnement 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, les chiffres annoncés étaient encore plus ambitieux, 26% plus petit pour les images sans perte. Sur un web où les images représentent environ la moitié des données transférées, ces économies auraient dû entraîner une adoption massive. Ce n'est pas ce qui s'est passé.

L'acquisition qui a créé WebP

WebP n'est pas né dans un laboratoire d'images. Il est né dans 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 : ses codecs alimentaient la vidéo Flash, les appels vidéo Skype et le streaming AOL. Son 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 sans référence aux autres frames, fonctionnait essentiellement comme 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 le format était conçu pour le web. « P » parce que les formats d'image se terminent souvent 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. Les deux étaient bien installés. Pourquoi s'embêter ?

JPEG souffrait de limites bien connues :

• Pas de transparence. Un pixel JPEG est soit totalement opaque, soit il faut 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.

PNG avait des limites tout aussi marquées :

• Pas de mode avec perte. PNG est toujours sans perte. Une photographie de 12 MP en PNG fait facilement 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, avec quelques différences clés :

L'intra prediction est le principal 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 nettement.

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 demandait 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é qui combine plusieurs techniques :

• 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 diminuer 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 vous fiez pas à 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 a des avantages concrets sur certains points.

Les fichiers sont 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.

Il consolide aussi plusieurs fonctionnalités dans un seul format. 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.

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

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.

Enfin, 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

WebP souffre surtout de lacunes qui tiennent à son écosystème, pas à sa compression brute.

La vitesse d'encodage en est une. 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. Cela compte toujours pour les workflows par lots. Un photographe exportant 1 000 images attendra sensiblement plus longtemps.

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

Il ne permet pas non plus de recompresser un JPEG existant sans perte. JPEG XL peut prendre un JPEG 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.

Le support des outils a longtemps été incomplet. 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.

Enfin, le nuage de brevets VP8 a freiné certaines adoptions. 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.

Ce n'est pas une question de technique, mais d'effets de réseau et de coûts de transition.

JPEG est le QWERTY des formats d'image. Chaque appareil photo enregistre JPEG par défaut. Chaque téléphone l'affiche nativement. Chaque imprimante l'accepte. 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 et les newsletters par email, a avancé lentement ou pas du tout.

Le point de blocage principal é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'a pas totalement échoué, mais il reste 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 :

L'héritage de WebP, c'est d'avoir montré que le web peut adopter un nouveau format d'image quand un grand éditeur de navigateur le pousse. Il a prouvé qu'un format post-JPEG était possible, ce qui a aidé AVIF à entrer dans les navigateurs, poussé Apple à prendre en charge d'autres formats que JPEG/PNG, et démontré que transparence et animation pouvaient tenir dans un même conteneur.

Mais il a aussi montré qu'un meilleur taux de compression ne suffit pas à imposer un format. L'ubiquité, l'inertie et la cohérence de l'écosystème pèsent plus que les performances brutes. JPEG survivra à WebP non pas parce qu'il est meilleur, mais parce qu'il est déjà partout.

Ce que cette histoire laisse entendre

WebP a été construit à partir d'un codec vidéo pour résoudre un problème de bande passante. Il l'a résolu, 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 ressemble au 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, en jouant le même rôle que PNG 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, sans upload ni 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.