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

Abre un archivo WebP en un editor hexadecimal. Los primeros doce bytes:

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

Esa es la cabecera de contenedor estilo 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, igual que el audio WAV o el vídeo AVI, construido a partir de 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. Esa decisión de diseño — usar un códec de vídeo para fotografías — es el elemento más importante para compreender 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 afirmación era aún más audaz: 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 deberían haber sido suficientes 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 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 el grupo de licencias H.264 de MPEG-LA, que empezaba a exigir 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 — la compresión de un único fotograma de vídeo sin referencia a otros fotogramas — era esencialmente un códec de imágenes estáticas. Los mismos modos de predicción, la codificación por transformada y la codificación entrópica que hacían eficiente a VP8 para vídeo también funcionaban 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 los formatos de imagen terminan 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?

Las limitaciones de JPEG eran 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.

Las limitaciones de PNG eran igualmente reales:

• 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 de WebP almacena un flujo de bits VP8 dentro de un contenedor RIFF. El flujo de codificación es conceptualmente similar a JPEG, pero con diferencias clave:

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 es mínimo 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 — típicamente un 5-10% de ahorro adicional 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: 14 modos de predicción espacial diferentes por píxel.
• Caché de color: Una tabla hash de colores recientemente vistos para aprovechar la repetición local.
• Back-references LZ77: Como el DEFLATE de PNG, pero con una coincidencia 2D consciente del espacio.
• Híbrido Huffman + aritmético: La codificación entrópica 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 extiende WebP con características adicionales:

• Alpha channel: Alpha de 8 bits codificada por separado, comprimida con el codificador entrópico de WebP sin pérdida.
• Animación: Múltiples fotogramas con metadatos de tiempo, esencialmente un vídeo VP8 simplificado.
• Metadatos EXIF: Datos de cámara y geolocalización.
• Metadatos XMP: Instrucciones de procesado al estilo Adobe.
• Perfil de color ICC: Gestión de color de 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 es técnicamente impresionante en dimensiones específicas:

Archivos 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. El modo sin pérdida de WebP fue de media un 26% más pequeño que PNG. Para sitios de alto tráfico, esos ahorros se traducen directamente en costes de ancho de banda y cargas de página más rápidas.

Consolidación de características: Un solo formato sustituye a JPEG y PNG en la mayoría de casos de uso. Modo con pérdida para fotos, modo sin pérdida para gráficos, alpha channel para transparencia, animación para secuencias cortas. Un desarrollador web necesita conocer un formato en lugar de tres.

Decodificación nativa en navegadores: Chrome, Firefox, Safari y Edge integran descodificadores WebP acelerados por hardware o altamente optimizados por software. La velocidad de decodificación es comparable a JPEG en escritorio y dentro de un 10-20% en móvil.

Decodificación progresiva: WebP soporta visualización incremental a medida que llegan los datos, similar al modo progresivo de JPEG. Para conexiones lentas, una imagen reconocible aparece tras recibir aproximadamente el 30% del archivo.

Animación: Los archivos WebP animados son típicamente 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 son técnicos. Son ecológicos.

Velocidad de codificación: En 2010, la codificación WebP era aproximadamente 8 veces más lenta 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 1.000 imágenes esperará notablemente más.

Sin soporte de 16 bits ni HDR: WebP es estrictamente de 8 bits por canal. Para fotografía de gama amplia, imagen médica o contenido HDR, WebP no sirve. HEIC, AVIF y JPEG XL soportan mayores profundidades de bits.

Sin recompresión sin pérdida de JPEG: JPEG XL puede tomar un JPEG existente y recomprimirlo sin pérdida para un ahorro de aproximadamente el 20%. WebP no puede. Convertir un JPEG a WebP requiere codificación completa, lo que introduce generation loss.

Brechas en herramientas: Photoshop no soportó WebP de forma nativa hasta 2022. El soporte WebP de ImageMagick requería compilar un plugin de libwebp, que muchas distribuciones omitían por defecto. Muchos sistemas de gestión de contenido siguen generando JPEG/PNG por defecto.

La nube de patentes de VP8: Google publicó VP8 con una promesa de indemnización de patentes, pero el panorama de patentes del códec nunca fue tan limpio como el de PNG o JPEG. Algunas organizaciones evitaron WebP específicamente porque no confiaban en que el escudo legal de Google resistiera en un tribunal.

Por qué ganó el formato "inferior"

JPEG tiene treinta y cuatro años. No tiene transparencia, ni animación, ni modo sin pérdida, y presenta 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. Son los efectos de red y los costes de cambio.

JPEG es el QWERTY de los formatos de imagen. Todas las cámaras guardan JPEG por defecto. Todos los teléfonos muestran JPEG de forma nativa. Todas las impresoras aceptan JPEG. Todas las redes sociales, CMS, CDN y clientes de correo gestionan JPEG sin plugins, códecs ni conversión. El formato es tan universal que "imagen" y "JPEG" son funcionalmente sinónimos para la mayoría de usuarios.

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 punto crítico de fracaso fue el ecosistema de Apple. 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 siendo superado por la siguiente generación.

Dónde se sitúa WebP hoy

WebP no es un fracaso. Es un éxito parcial.

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 nicho 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:

El legado real de WebP es demostrar que la web puede adoptar nuevos formatos de imagen cuando un fabricante de navegadores importante presiona lo suficiente. Allanó el camino para AVIF. Obligó a Apple a soportar formatos distintos de JPEG/PNG de forma nativa. Demostró que la transparencia y la animación pertenecen a un único contenedor.

Pero también demostró que la superioridad técnica no basta. La ubicuidad, la inercia y la alineación del ecosistema importan más que las tasas de compresión. JPEG sobrevivirá a WebP no porque sea mejor, sino porque ya está en todas partes.

La conclusión

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, 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 porque un artículo técnico dice que el nuevo es un 25% más pequeño. Cambia cuando el nuevo formato es 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ó fácil, AVIF ya había llegado con un número mayor en la ficha técnica.

WebP es el Betamax de los formatos de imagen — técnicamente sólido, bien soportado y finalmente superado por algo que llegó ligeramente después con mejor marketing y respaldo más amplio. No desaparecerá. Coexistirá con JPEG, PNG, AVIF y lo que venga después, desempeñando el mismo papel que PNG cumple hoy: el fallback seguro y capaz 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, sin procesamiento en servidor. Para JPEGs que necesitan transparencia o animación, JPG to WebP gestiona la conversión con control de calidad. Y cuando necesites el fallback universal, WebP to PNG y WebP to JPG devuelven los archivos WebP a formatos que se abren en cualquier visor.