Nascimento do WebP: VP8 como formato de imagem

Abre um ficheiro WebP num editor hexadecimal. Os primeiros doze bytes:

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

Este é o cabeçalho de contentor no estilo RIFF/WAVE. 52 49 46 46 soletra "RIFF" em ASCII. Os quatro bytes seguintes são o tamanho do ficheiro em uint32 little-endian. 57 45 42 50 soletra "WEBP". Um ficheiro WebP não é um fluxo de bits em bruto. É um contentor, tal como o áudio WAV ou o vídeo AVI, construído a partir da mesma especificação RIFF que a Microsoft introduziu em 1991. Dentro desse contentor repousa um fotograma de vídeo VP8, reaproveitado para uma imagem estática. Essa escolha de design — usar um códec de vídeo para fotografias — é a coisa mais importante a compreender sobre o WebP.

A Google anunciou o WebP a 30 de setembro de 2010. A proposta era simples: a mesma qualidade visual que o JPEG, mas 25-34% mais pequeno. Para o PNG, a afirmação era ainda mais ousada — 26% mais pequeno para imagens sem perda. Numa web onde os bytes de imagem representam cerca de metade de todos os dados transferidos, esses números deveriam ter sido suficientes para desencadear uma adoção em massa. Não foram.

A Aquisição que Criou o WebP

O WebP não surgiu num laboratório de imagens. Surge de um códec de vídeo.

Em fevereiro de 2010, a Google adquiriu a On2 Technologies por aproximadamente 124 milhões de dólares. A On2 era uma empresa de compressão de vídeo com uma longa história — os seus códecs alimentavam o vídeo Flash, as chamadas de vídeo do Skype e o streaming da AOL. O seu produto de topo era o VP8, um códec de vídeo concebido para competir com o H.264 sem royalties de patentes.

A Google tornou o VP8 open-source em maio de 2010 sob o nome WebM, agrupando-o com o códec de áudio Vorbis e o contentor Matroska. O objetivo era claro: construir uma stack de vídeo livre de patentes para desafiar o conjunto de licenciamento H.264 da MPEG-LA, que começava a exigir royalties do streaming de vídeo na web.

Mas a Google tinha um segundo caso de uso em mente. A compressão intra-fotograma do VP8 — a compressão de um único fotograma de vídeo sem referência a outros fotogramas — era essencialmente um códec de imagens estáticas. Os mesmos modos de predição, codificação por transformada e codificação entropica que tornavam o VP8 eficiente para vídeo também funcionavam para fotografias. A Google extraiu o modo intra-fotograma, encapsulou-o num contentor RIFF e chamou-lhe WebP.

O nome foi uma escolha de marketing. "Web" porque foi concebido para a web. "P" porque os formatos de imagem terminam em P — JPEG, PNG, BMP, TIFF. O resultado foi um formato que tecnicamente era um fotograma de vídeo a fazer-se passar por uma fotografia.

Porque Construir um Novo Formato?

Em 2010, o JPEG tinha dezoito anos e o PNG tinha catorze. Ambos estavam consolidados. Por que se dar ao trabalho?

As limitações do JPEG eram reais e bem conhecidas:

• Sem transparência. Um pixel JPEG é totalmente opaco ou precisa de uma máscara separada.
• Sem animação. O JPEG animado não existe como padrão.
• Apenas com perda. A especificação base do JPEG não tem modo sem perda. (O JPEG-LS e o JPEG 2000 existem, mas nenhum é compatível com a web.)
• Profundidade de cor de 8 bits por canal. Sem suporte a gamut alargado ou HDR na base.
• Artefactos de bloco em baixa qualidade. A grelha DCT de 8 x 8 é visível em definições de qualidade abaixo de 75.

As limitações do PNG eram igualmente reais:

• Sem modo com perda. O PNG é sempre sem perda. Uma fotografia de 12 MP em PNG ocupa 15-25 MB.
• Ficheiros grandes para fotografias. A compressão DEFLATE do PNG não consegue competir com a descarte psico-visual baseado em DCT.
• Sem animação na especificação base. O APNG existe, mas demorou anos a ganhar suporte nos navegadores.

A Google viu uma lacuna: um único formato que pudesse fazer compressão com perda e sem perda, transparência e animação, tudo em ficheiros mais pequenos que os incumbentes. Essa era a proposta do WebP.

Como o WebP Funciona de Facto

O WebP tem dois formatos internos fundamentalmente diferentes: WebP com perda (VP8 intra-fotograma) e WebP sem perda (um códec separado, também derivado da pesquisa VP8).

WebP com perda: VP8 Intra

O modo com perda do WebP armazena um fluxo de bits VP8 dentro de um contentor RIFF. O pipeline de codificação é conceptualmente semelhante ao JPEG, mas com diferenças-chave:

A predição intra é a maior vantagem. O JPEG codifica cada bloco 8 x 8 independentemente. O WebP prediz cada bloco 4 x 4 a partir dos vizinhos já codificados — topo, esquerda, ou ambos — e depois codifica apenas o erro de predição. Para gradientes suaves e grandes regiões planas, o erro é mínimo, e o rácio de compressão melhora significativamente.

O codificador aritmético também é mais eficiente que a codificação de Huffman do JPEG — tipicamente 5-10% de poupança adicional para a mesma qualidade.

Os benchmarks da própria Google de 2010 afirmavam:

A velocidade de codificação era o custo oculto. Produzir um ficheiro WebP exigia significativamente mais CPU que o JPEG. Para fotógrafos a exportarem centenas de imagens, isso importava.

WebP sem perda

O modo sem perda do WebP usa um códec completamente diferente. Não é VP8. É um formato personalizado que combina:

• Codificação preditiva: 14 modos diferentes de predição espacial por pixel.
• Cache de cor: Uma tabela hash de cores vistas recentemente para explorar a repetição local.
• LZ77 back-references: Tal como o DEFLATE do PNG, mas com correspondência 2D consciente do espaço.
• Híbrido Huffman + aritmético: A codificação entropica adapta-se às estatísticas locais.

A Google afirmava ficheiros 26% mais pequenos que o PNG em média. Na prática, as poupanças variam imenso — gráficos simples com grandes regiões planas vêm pouco benefício, enquanto fotografias com textura fina podem ver reduções de 30-40%.

WebP expandido (VP8X)

O chunk VP8X estende o WebP com funcionalidades adicionais:

• Canal alfa: Alpha de 8 bits codificado separadamente, comprimido com o codificador entropico do WebP sem perda.
• Animação: Múltiplos fotogramas com metadados de temporização, essencialmente um vídeo VP8 simplificado.
• Metadados EXIF: Dados da câmara e geolocalização.
• Metadados XMP: Instruções de processamento ao estilo Adobe.
• Perfil de cor ICC: Gestão de cor para gamut alargado e HDR.

Um ficheiro VP8X começa com um cabeçalho de chunk VP8X, seguido de flags que indicam quais extensões estão presentes.

O Formato do Ficheiro

O WebP é um contentor RIFF. Compreender o layout de bytes é direto se conheceres o RIFF.

Estrutura do Contentor RIFF

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

Cabeçalho Expandido VP8X

Se o FourCC nos bytes 12-15 for "VP8X" (0x56 0x50 0x38 0x58):

Bytes 20-23: Tamanho do chunk = 10 (uint32 little-endian)
Bytes 24:    Byte de flags
             Bit 0: Animação presente
             Bit 1: Metadados XMP presentes
             Bit 2: Metadados EXIF presentes
             Bit 3: Alpha channel presente
             Bit 4: Perfil ICC presente
             Bits 5-7: Reservados
Bytes 25-27: Largura do canvas - 1 (uint24 little-endian)
Bytes 28-30: Altura do canvas - 1 (uint24 little-endian)

As dimensões do canvas são armazenadas como largura - 1 e altura - 1, por isso uma imagem de 1200 x 675 armazena 1199 e 674. O tamanho máximo do canvas é 16.777.215 x 16.777.215 pixels.

Tipos de Chunk

Detetar WebP ao Ler a Assinatura do Ficheiro

Não confies na extensão .webp. Lê os primeiros 16 bytes e analisa o cabeçalho RIFF.

Layout exato de bytes de um WebP com perda simples:

Bytes 0-3:   "RIFF"
Bytes 4-7:   Tamanho do ficheiro (uint32 little-endian)
Bytes 8-11:  "WEBP"
Bytes 12-15: "VP8 " (com perda) ou "VP8L" (sem perda) ou "VP8X" (expandido)

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

Opção de nível superior com 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 com a biblioteca 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"];
}

Com 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)

Extração completa de metadados:

magick identify -verbose image.webp

Isto devolve largura, altura, profundidade de cor, presença de alpha, tipo de compressão e informação do perfil ICC.

Ou simplesmente:

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

Os Pontos Fortes

O WebP é tecnicamente impressionante em dimensões específicas:

Ficheiros mais pequenos: No corpus de referência da Google, o WebP com perda médio era 25-34% mais pequeno que o JPEG no mesmo SSIM. O WebP sem perda médio era 26% mais pequeno que o PNG. Para sites de alto tráfego, essas poupanças traduzem-se diretamente em custos de largura de banda e carregamentos de página mais rápidos.

Consolidação de funcionalidades: Um formato substitui tanto o JPEG como o PNG para a maioria dos casos de uso. Modo com perda para fotografias, modo sem perda para gráficos, canal alfa para transparência, animação para sequências curtas. Um programador web precisa de conhecer um formato em vez de três.

Decodificação nativa no navegador: O Chrome, Firefox, Safari e Edge incluem todos descodificadores WebP acelerados por hardware ou altamente otimizados por software. A velocidade de decodificação é comparável ao JPEG no desktop e dentro de 10-20% no telemóvel.

Decodificação progressiva: O WebP suporta exibição incremental à medida que os dados chegam, semelhante ao modo progressivo do JPEG. Para ligações lentas, uma imagem reconhecível aparece após receber ~30% do ficheiro.

Animação: Ficheiros WebP animados são tipicamente 60-80% mais pequenos que GIFs animados em qualidade visual equivalente, com cor a 24 bits e alfa de 8 bits por fotograma.

Os Pontos Fracos

Os problemas do WebP não são técnicos. São ecológicos.

Velocidade de codificação: Em 2010, a codificação WebP era aproximadamente 8x mais lenta que o libjpeg. A lacuna estreitou — o libwebp em 2026 é cerca de 2-3x mais lento que o libjpeg-turbo — mas ainda importa para fluxos de trabalho em lote. Um fotógrafo a exportar 1.000 imagens esperará notoriamente mais tempo.

Sem suporte a 16 bits ou HDR: O WebP é estritamente 8 bits por canal. Para fotografia de gamut alargado, imagens médicas ou conteúdo HDR, o WebP é inutilizável. O HEIC, AVIF e JPEG XL suportam todas profundidades de bits superiores.

Sem recompressão sem perda de JPEG: O JPEG XL pode pegar num JPEG existente e recompressá-lo sem perda para ~20% de poupança. O WebP não consegue. Converter um JPEG para WebP exige recodificação completa, o que introduz generation loss.

Limitações das ferramentas: O Photoshop não suportou WebP nativamente até 2022. O suporte WebP do ImageMagick exigia compilação de um plugin libwebp, que muitas distribuições omitiam por omissão. Muitos sistemas de gestão de conteúdo ainda geram JPEG/PNG por omissão.

A nuvem de patentes do VP8: A Google lançou o VP8 com uma promessa de indemnização de patentes, mas o panorama de patentes do códec nunca foi tão limpo como o do PNG ou do JPEG. Algumas organizações evitaram o WebP precisamente porque não confiavam que o escudo legal da Google se sustentasse em tribunal.

Porque o Formato "Inferior" Venceu

O JPEG tem trinta e quatro anos. Não tem transparência, animação, modo sem perda, e apresenta artefactos visíveis em qualidade 75. O WebP vence-o em quase todas as métricas. Ainda assim, o Web Almanac de 2025 coloca o JPEG em cerca de 46% de todas as imagens web contra 19% do WebP.

A razão não é técnica. São efeitos de rede e custos de mudança.

O JPEG é o QWERTY dos formatos de imagem. Cada câmara guarda JPEG por omissão. Cada telemóvel mostra JPEG nativamente. Cada impressora aceita JPEG. Cada rede social, CMS, CDN e cliente de email processa JPEG sem plugins, códecs ou conversão. O formato é tão universal que "imagem" e "JPEG" são funcionalmente sinónimos para a maioria dos utilizadores.

A curva de adoção do WebP conta a história:

O Chrome empurrou o WebP agressivamente porque a Google controlava tanto o navegador como o formato. O Facebook adotou-o porque poupava petabytes de largura de banda. Mas a cauda longa da web — blogs WordPress, pequenos sites de comércio eletrónico, implantações empresariais de CMS, newsletters por email — moveu-se lentamente ou nem se moveu.

O ponto de falha crítico foi o ecossistema da Apple. Os iPhones guardavam HEIC por omissão, não WebP. O Preview do macOS não suportou WebP até ao macOS 11 Big Sur (2020). O menu de partilha do iOS não oferecia exportação WebP. Para fotógrafos, designers e criadores de redes sociais que trabalham principalmente em dispositivos Apple, o WebP era invisível.

Entretanto, o AVIF chegou em 2019 com melhor compressão que o WebP e licenciamento livre de royalties da Alliance for Open Media. O Chrome, Firefox e Safari incluem todos AVIF. A Cloudflare e a Cloudinary servem AVIF automaticamente. O WebP tornou-se um degrau — melhor que o JPEG, mas já a ser ultrapassado pela próxima geração.

Onde o WebP Se Situa Hoje

O WebP não é um fracasso. É um sucesso parcial.

Para programadores web a construir projetos novos em 2026, o WebP é a escolha pragmática por omissão para imagens que precisam de transparência ou animação. É mais pequeno que o PNG para gráficos sem perda e mais pequeno que o JPEG para fotografias. O suporte nos navegadores é universal. As ferramentas de codificação são maduras.

Mas o WebP não substituiu o JPEG. Esculpiu um nicho ao lado dele — o mesmo nicho que o PNG já ocupava, apenas com ficheiros mais pequenos. A visão de "um formato para todas as imagens" não se materializou.

A realidade prática para 2026:

O legado real do WebP é provar que a web pode adotar novos formatos de imagem quando um grande fornecedor de navegadores empurra com força suficiente. Abriu caminho ao AVIF. Forçou a Apple a suportar formatos não-JPEG/PNG nativamente. Mostrou que transparência e animação pertencem num único contentor.

Mas também provou que a superioridade técnica não basta. A ubiquidade, a inércia e o alinhamento do ecossistema importam mais que os rácios de compressão. O JPEG sobreviverá ao WebP não porque seja melhor, mas porque já está em todo o lado.

A Conclusão

O WebP foi construído a partir de um códec de vídeo para resolver um problema de largura de banda. Resolveu esse problema — para a Google, para o Facebook, para qualquer site disposto a converter o seu pipeline de imagens. A compressão é real, as funcionalidades são úteis, e o suporte nos navegadores é completo.

Mas a web não muda de formato porque um white paper diz que o novo é 25% mais pequeno. Muda quando o novo formato é mais fácil de usar que o antigo, ou quando o antigo falha tão gravemente que a migração é inevitável. O JPEG não falhou gravemente o suficiente. O WebP não foi fácil o suficiente. E quando o WebP se tornou fácil, o AVIF já tinha chegado com um número maior na ficha técnica.

O WebP é o Betamax dos formatos de imagem — tecnicamente sólido, bem suportado, e ultrapassado por algo que chegou ligeiramente depois com melhor marketing e apoio mais amplo. Não vai desaparecer. Vai coexistir com o JPEG, PNG, AVIF e o que vier a seguir, desempenhando o mesmo papel que o PNG desempenha hoje: o fallback seguro e capaz que funciona em todo o lado.

Se tens ficheiros PNG que precisam de pegadas mais pequenas para a web, PNG to WebP converte-os localmente no teu navegador — sem uploads, sem processamento no servidor. Para JPEGs que precisam de transparência ou animação, JPG to WebP trata da conversão com controlo de qualidade. E quando precisas do fallback universal, WebP to PNG e WebP to JPG trazem ficheiros WebP de volta a formatos que abrem em todos os visualizadores.