El nacimiento de WebP: VP8, de vídeo a imagen

Los primeros doce bytes de un archivo WebP se ven así en un editor hexadecimal:

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

Esa es la cabecera de un contenedor RIFF/WAVE. 52 49 46 46 deletrea "RIFF" en ASCII. Los siguientes cuatro bytes son el tamaño del archivo en uint32 little-endian. 57 45 42 50 deletrea "WEBP". Un archivo WebP no es un flujo de bits en bruto. Es un contenedor, como el audio WAV o el vídeo AVI, construido con la misma especificación RIFF que Microsoft introdujo en 1991. Dentro de ese contenedor reside un fotograma de vídeo VP8, reconvertido en imagen estática. Usar un códec de vídeo para fotografías es la decisión de diseño que más ayuda a entender WebP.

Google anunció WebP el 30 de septiembre de 2010. La propuesta era simple: misma calidad visual que JPEG, pero un 25-34% más pequeño. Para PNG, la promesa era todavía más agresiva: un 26% más pequeño para imágenes sin pérdida. En una web donde los bytes de imagen representan aproximadamente la mitad de todos los datos transferidos, esos números parecían deber bastar para desencadenar una adopción masiva. No lo fueron.

La adquisición que creó WebP

WebP no surgió de un laboratorio de imágenes. Surgió de un códec de vídeo.

En febrero de 2010, Google adquirió On2 Technologies por aproximadamente 124 millones de dólares. On2 era una empresa de compresión de vídeo con una larga trayectoria: sus códecs impulsaban el vídeo Flash, las videollamadas de Skype y el streaming de AOL. Su producto estrella era VP8, un códec de vídeo diseñado para competir con H.264 sin pagar royalties de patente.

Google publicó VP8 como código abierto en mayo de 2010 bajo el nombre WebM, empaquetándolo con el códec de audio Vorbis y el contenedor Matroska. El objetivo era claro: construir una pila de vídeo libre de patentes para desafiar al grupo de licencias H.264 de MPEG-LA, que empezaba a cobrar royalties por el streaming de vídeo en la web.

Pero Google tenía un segundo caso de uso en mente. La compresión intra-fotograma de VP8, es decir, la compresión de un único fotograma de vídeo sin referencia a otros fotogramas, era básicamente un códec de imágenes estáticas. Los modos de predicción, la transformada y la codificación entrópica que hacían eficiente a VP8 para vídeo también servían para fotografías. Google extrajo el modo intra-fotograma, lo envolvió en un contenedor RIFF y lo llamó WebP.

El nombre fue una elección de marketing. "Web" porque estaba diseñado para la web. "P" porque casi todos los formatos de imagen acaban en P (JPEG, PNG, BMP, TIFF). El resultado fue un formato que, técnicamente, era un fotograma de vídeo fingiendo ser una foto.

¿Por qué crear un nuevo formato?

En 2010, JPEG tenía dieciocho años y PNG tenía catorce. Ambos estaban arraigados. ¿Por qué molestarse?

JPEG tenía limitaciones reales y bien conocidas:

• Sin transparencia. Un píxel JPEG es completamente opaco o necesita una máscara separada.
• Sin animación. El JPEG animado no existe como estándar.
• Solo con pérdida. La especificación base de JPEG no tiene modo sin pérdida. (JPEG-LS y JPEG 2000 existen, pero ninguno es compatible con la web.)
• Profundidad de color de 8 bits por canal. Sin soporte de gama amplia ni HDR en la especificación base.
• Artefactos de bloque a baja calidad. La cuadrícula DCT de 8 x 8 es visible con ajustes de calidad inferiores a 75.

PNG tenía sus propias limitaciones:

• Sin modo con pérdida. PNG es siempre sin pérdida. Una fotografía de 12 MP en PNG ocupa 15-25 MB.
• Archivos grandes para fotografías. La compresión DEFLATE de PNG no puede competir con el descarte psicovisual basado en DCT.
• Sin animación en la especificación base. APNG existe, pero tardó años en ganar soporte en navegadores.

Google identificó una brecha: un único formato capaz de ofrecer compresión con pérdida y sin pérdida, transparencia y animación, todo en archivos más pequeños que los formatos establecidos. Esa fue la propuesta de WebP.

Cómo funciona WebP realmente

WebP tiene dos formatos internos fundamentalmente distintos: WebP con pérdida (VP8 intra-fotograma) y WebP sin pérdida (un códec separado, también derivado de la investigación de VP8).

WebP con pérdida: VP8 Intra

El modo con pérdida guarda un flujo de bits VP8 dentro del contenedor RIFF. Se parece a JPEG, con algunas diferencias importantes:

La predicción intra es la mayor ventaja. JPEG codifica cada bloque de 8 x 8 de forma independiente. WebP predice cada bloque de 4 x 4 a partir de sus vecinos ya codificados (superior, izquierdo o ambos) y luego codifica solo el error de predicción. Para gradientes suaves y regiones planas grandes, el error resulta pequeño y la tasa de compresión mejora significativamente.

El codificador aritmético también es más eficiente que la codificación de Huffman de JPEG, con un ahorro adicional típico del 5-10% para la misma calidad.

Los propios benchmarks de Google de 2010 afirmaban:

La velocidad de codificación era el coste oculto. Producir un archivo WebP requería significativamente más CPU que JPEG. Para fotógrafos que exportan cientos de imágenes, eso importaba.

WebP sin pérdida

El modo sin pérdida de WebP utiliza un códec completamente diferente. No es VP8. Es un formato personalizado que combina codificación predictiva con 14 modos de predicción espacial por píxel, una tabla hash de colores recientemente vistos (la caché de color), back-references LZ77 con coincidencias 2D conscientes del espacio (parecido al DEFLATE de PNG, pero adaptado a imágenes) y una codificación entrópica híbrida de Huffman y aritmética que se adapta a las estadísticas locales.

Google afirmaba archivos un 26% más pequeños que PNG de media. En la práctica, el ahorro varía enormemente: los gráficos simples con regiones planas grandes apenas se benefician, mientras que las fotografías con textura fina pueden reducirse un 30-40%.

WebP extendido (VP8X)

El chunk VP8X añade alpha de 8 bits (codificada por separado y comprimida con el codificador entrópico sin pérdida), animación mediante múltiples fotogramas con metadatos de tiempo (un vídeo VP8 simplificado), metadatos EXIF con datos de cámara y geolocalización, metadatos XMP con instrucciones de procesado al estilo Adobe y perfiles de color ICC para gestionar gama amplia y HDR.

Un archivo VP8X comienza con una cabecera de chunk VP8X, seguida de flags que indican qué extensiones están presentes.

El formato de archivo

WebP es un contenedor RIFF. Comprender la disposición de bytes es sencillo si conoces RIFF.

Estructura del contenedor RIFF

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

Cabecera extendida VP8X

Si el FourCC en los bytes 12-15 es "VP8X" (0x56 0x50 0x38 0x58):

Bytes 20-23: Tamaño del chunk = 10 (uint32 little-endian)
Bytes 24:    Byte de flags
             Bit 0: Animación presente
             Bit 1: Metadatos XMP presentes
             Bit 2: Metadatos EXIF presentes
             Bit 3: Alpha channel presente
             Bit 4: Perfil ICC presente
             Bits 5-7: Reservados
Bytes 25-27: Ancho del lienzo - 1 (uint24 little-endian)
Bytes 28-30: Alto del lienzo - 1 (uint24 little-endian)

Las dimensiones del lienzo se almacenan como ancho - 1 y alto - 1, así que una imagen de 1200 x 675 almacena 1199 y 674. El tamaño máximo del lienzo es 16.777.215 x 16.777.215 píxeles.

Tipos de chunk

Detectar WebP leyendo la firma del archivo

No confíes en la extensión .webp. Lee los primeros 16 bytes y analiza la cabecera RIFF.

Disposición exacta de bytes de un WebP con pérdida simple:

Bytes 0-3:   "RIFF"
Bytes 4-7:   Tamaño del archivo (uint32 little-endian)
Bytes 8-11:  "WEBP"
Bytes 12-15: "VP8 " (con pérdida) o "VP8L" (sin pérdida) o "VP8X" (extendido)

TypeScript en el navegador:

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"}

Opción de nivel superior 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)        # (ancho, alto)
    print(img.is_animated) # True si es animada

O con la librería 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)

Extracción completa de metadatos:

magick identify -verbose image.webp

Esto devuelve ancho, alto, profundidad de color, presencia de alpha, tipo de compresión e información del perfil ICC.

O simplemente:

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

Las fortalezas

WebP destaca en algunos aspectos concretos.

Los archivos son más pequeños. En el corpus de referencia de Google, el modo con pérdida de WebP fue de media un 25-34% más pequeño que JPEG con el mismo SSIM, y el modo sin pérdida un 26% más pequeño que PNG. Para sitios de alto tráfico, esos ahorros se traducen en menos ancho de banda y páginas que cargan antes.

También consolida funciones. Un solo formato cubre la mayoría de casos de uso de JPEG y PNG: modo con pérdida para fotos, modo sin pérdida para gráficos, canal alpha para transparencia y animación para secuencias cortas. El desarrollador web pasa de manejar tres formatos a uno solo.

La decodificación nativa en navegadores es otra ventaja. Chrome, Firefox, Safari y Edge integran descodificadores WebP acelerados por hardware o muy optimizados por software. En escritorio la velocidad es comparable a JPEG; en móvil ronda un 10-20% de diferencia.

WebP soporta decodificación progresiva, es decir, que la imagen se va mostrando a medida que llegan los datos, como el modo progresivo de JPEG. En conexiones lentas, una imagen reconocible aparece tras recibir aproximadamente el 30% del archivo.

La animación es el último punto fuerte. Los archivos WebP animados suelen ser un 60-80% más pequeños que los GIF animados con calidad visual equivalente, con color de 24 bits completo y alpha de 8 bits por fotograma.

Las debilidades

Los problemas de WebP no están en la especificación, sino en el ecosistema.

La codificación es lenta. En 2010, WebP codificaba unas ocho veces más despacio que libjpeg. La brecha se ha reducido (libwebp en 2026 es unas 2-3 veces más lento que libjpeg-turbo), pero sigue siendo relevante para flujos de trabajo por lotes. Un fotógrafo que exporta mil imágenes notará la diferencia.

WebP se queda en 8 bits por canal, así que no sirve para fotografía de gama amplia, imagen médica o contenido HDR. HEIC, AVIF y JPEG XL sí soportan mayores profundidades de bits.

Tampoco permite recomprimir JPEG sin pérdida. JPEG XL puede tomar un JPEG existente y reducirlo un 20% aproximadamente sin perder información. WebP no puede: convertir un JPEG a WebP exige codificar de nuevo la imagen, lo que introduce pérdida de generación.

El soporte en herramientas ha sido irregular. Photoshop no añadió exportación nativa de WebP hasta 2022. En ImageMagick hacía falta compilar un plugin de libwebp, y muchas distribuciones lo omitían por defecto. Muchos CMS siguen generando JPEG o PNG por defecto.

El entorno de patentes de VP8 también inquietaba. Google ofreció indemnización, pero el panorama nunca fue tan limpio como el de PNG o JPEG. Algunas organizaciones evitaron WebP porque no confiaban en que el escudo legal de Google aguantara en un tribunal.

Por qué ganó el formato "inferior"

JPEG tiene treinta y cuatro años. Sigue sin transparencia, animación ni modo sin pérdida, y muestra artefactos visibles a calidad 75. WebP lo supera en casi todas las métricas. Sin embargo, el Web Almanac de 2025 sitúa a JPEG en aproximadamente el 46% de todas las imágenes de la web frente al 19% de WebP.

La razón no es técnica; se explica por los efectos de red y los costes de cambio.

JPEG es demasiado extendido para desplazarlo. Las cámaras, los teléfonos, las impresoras, las redes sociales, los CMS, los CDN y los clientes de correo lo gestionan sin plugins, códecs ni conversión. Para la mayoría de usuarios, "imagen" e "JPEG" son prácticamente sinónimos.

La curva de adopción de WebP cuenta la historia:

Chrome impulsó WebP agresivamente porque Google controlaba tanto el navegador como el formato. Facebook lo adoptó porque ahorraba petabytes de ancho de banda. Pero la cola larga de la web (blogs de WordPress, pequeñas tiendas de comercio electrónico, despliegues empresariales de CMS, newsletters por correo) avanzó lentamente o no lo hizo en absoluto.

El ecosistema de Apple fue el obstáculo más difícil. Los iPhones guardaban HEIC por defecto, no WebP. La Vista Previa de macOS no soportó WebP hasta macOS 11 Big Sur (2020). La hoja de compartir de iOS no ofrecía exportación en WebP. Para fotógrafos, diseñadores y creadores de redes sociales que trabajaban principalmente en dispositivos Apple, WebP era invisible.

Mientras tanto, AVIF llegó en 2019 con mejor compresión que WebP y licencias libres de royalties de la Alliance for Open Media. Chrome, Firefox y Safari integran AVIF. Cloudflare y Cloudinary sirven AVIF automáticamente. WebP se convirtió en un peldaño: mejor que JPEG, pero ya superado por la siguiente generación.

Dónde se sitúa WebP hoy

WebP se ha quedado a medio camino: no es un fracaso, pero tampoco cumplió toda la promesa.

Para desarrolladores web que construyen proyectos nuevos en 2026, WebP es la opción pragmática por defecto para imágenes que necesitan transparencia o animación. Es más pequeño que PNG para gráficos sin pérdida y más pequeño que JPEG para fotografías. El soporte en navegadores es universal. Las herramientas de codificación están maduras.

Pero WebP no sustituyó a JPEG. Se abrió un nicho junto a él, el mismo que PNG ya ocupaba, solo con archivos más pequeños. La visión de "un formato para todas las imágenes" no se materializó.

La realidad práctica para 2026:

WebP dejó dos lecciones claras. La primera es que la web sí puede adoptar un nuevo formato de imagen si un gran fabricante de navegadores empuja lo suficiente. La segunda es que la adopción no depende solo de la compresión. WebP abrió la puerta a AVIF, forzó a Apple a soportar formatos distintos de JPEG y PNG de forma nativa y demostró que transparencia y animación pueden convivir en un único contenedor.

También demostró que ganar en la ficha técnica no es suficiente. La ubicuidad y la inercia del ecosistema pesan más que unos puntos porcentuales de compresión. JPEG no sobrevive porque sea mejor; sobrevive porque ya está en todas partes.

Qué pasó al final

WebP se construyó a partir de un códec de vídeo para resolver un problema de ancho de banda. Ese problema lo resolvió para Google, para Facebook y para cualquier sitio dispuesto a convertir su canalización de imágenes. La compresión es real, las características son útiles y el soporte en navegadores es completo.

Pero la web no cambia de formato solo porque un artículo técnico diga que el nuevo es un 25% más pequeño. Cambia cuando el nuevo formato resulta claramente más fácil de usar que el antiguo, o cuando el antiguo falla tanto que la migración es inevitable. JPEG no falló lo suficiente, WebP no fue lo suficientemente fácil y, para cuando WebP se volvió sencillo, AVIF ya había llegado con mejores cifras en la ficha técnica.

WebP es técnicamente sólido y está bien soportado, pero quedó superado por AVIF, que llegó poco después con mejores cifras y más respaldo. No va a desaparecer. Seguirá coexistiendo con JPEG, PNG, AVIF y lo que venga después, como un fallback seguro que funciona en todas partes.

Si tienes archivos PNG que necesitan un tamaño menor para la web, PNG to WebP los convierte localmente en tu navegador, sin subidas y sin procesamiento en servidor. Para JPEGs que necesitan transparencia o animación, JPG to WebP gestiona la conversión con control de calidad. Cuando necesites el fallback universal, WebP to PNG y WebP to JPG devuelven los archivos WebP a formatos que se abren en cualquier visor.