WebP vs AVIF vs JPEG: ¿qué formato de imagen elegir en 2026?

Resumen rápido: AVIF es un 20–30 % más pequeño que WebP y un 30–50 % más pequeño que JPEG. WebP es aproximadamente un 25–35 % más pequeño que JPEG. AVIF codifica 5–20× más lento que WebP, mientras que WebP es el más rápido de los tres al decodificar. La receta que funciona en 2026: servir AVIF primero, caer a WebP, mantener JPEG como red de seguridad universal y dejar que el navegador elija mediante el elemento <picture>.

Esa respuesta cubre a casi todo el mundo. La pregunta interesante es cuándo no recurrir a AVIF. Sáltatelo cuando el presupuesto de CI sea ajustado y el tiempo de codificación pese más que los bytes ahorrados. Déjalo en pausa para subidas en tiempo real, porque la codificación AVIF en el navegador todavía es irregular. Mantén JPEG como principal si necesitas dar soporte a iOS 16.0–16.3 o a versiones antiguas de Edge en producción. En el resto de escenarios, AVIF gana en tamaño de archivo, siempre que tu marcado <picture> sea correcto y tu CDN envíe el MIME type adecuado.

Lo que viene después es el detalle operativo: cifras de soporte en 2026, un benchmark con foto real, un árbol de decisión por caso de uso, patrones <picture> listos para copiar, comandos de conversión y las cuatro trampas que cuestan tiempo a los equipos. Si solo quieres convertir y listo, nuestro compresor de imágenes gratuito procesa JPEG, PNG, WebP y AVIF en el navegador sin subir nada.

1. Soporte de navegadores en 2026: WebP al 97 %, AVIF al 93 %

Dos años y medio después de que Edge incorporara AVIF, la brecha de soporte se ha reducido a unos pocos puntos porcentuales del tráfico global. La pregunta ya no es “¿está soportado?”, sino “¿qué servimos al 3 % restante?“.

1.1 WebP: el predeterminado seguro

WebP llegó a Chrome en 2012, a Firefox 65 (2019), a Edge 18 (2018) y a Safari 14 (2020). En mayo de 2026, caniuse sitúa el soporte global en torno al 97 %. WebP pasó de “alternativa moderna” a “fallback viable”. Si vas a servir un único formato no JPEG, ese es WebP.

1.2 AVIF: ya es viable como formato principal

AVIF llegó en Chrome 85 (agosto de 2020) y Firefox 93 (octubre de 2021). Safari 16.4 lo habilitó en macOS e iOS en marzo de 2023. Edge fue el rezagado: solo añadió soporte de decodificación en la versión 121 (enero de 2024). La cobertura global en mayo de 2026 ronda el 93–95 %.

Una arista importante: iOS 16.0–16.3 tiene un bug conocido al decodificar AVIF que puede hacer que Safari falle con ciertas imágenes. Esas builds siguen vivas en dispositivos retenidos por MDM corporativo, así que servir AVIF sin un fallback funcional a WebP o JPEG es un riesgo real de caída visual. Trátalo como “principal con seguro”, no como “principal a secas”.

1.3 Matriz rápida de compatibilidad

Formato	Soporte global (mayo de 2026)	Limitación clave
JPEG	100 %	Archivos más grandes; sin transparencia; sin HDR
WebP	~97 %	Sin HDR ni color de 10 bits
AVIF	~93–95 %	Codificación lenta; bug de decodificación en iOS 16.0–16.3; requiere Edge 121+

2. Diferencias clave: compresión, velocidad, características

2.1 Eficiencia de compresión sobre una foto real

Un benchmark con la misma fuente: una foto de paisaje de 4000×3000, PNG original de unos 24 MB, recodificada con calidad perceptualmente equivalente:

Codificación	Tamaño	Frente a JPEG base
JPEG q75 (mozjpeg)	~2,1 MB	0 % (referencia)
WebP q75 (libwebp)	~1,4 MB	33 % menor
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	52 % menor

Aquí AVIF q60 es visualmente equivalente a JPEG q80 y WebP q75. Las escalas de calidad no son intercambiables entre códecs. Recodificar “JPEG q75 a AVIF q75” es el error clásico de quien empieza: terminas con un AVIF sobredimensionado que se ve idéntico a la fuente.

2.2 Velocidad de codificación: el impuesto de 5–20×

AVIF comprime más fuerte porque hace más trabajo. Con libavif a su cpu-used 4 por defecto, una imagen de 4000×3000 tarda 5–20× más que libwebp y unas 50× más que mozjpeg. Ese coste se acumula en builds de CI, arranques en frío de Lambda y pipelines que recodifican miles de assets.

Hay dos válvulas de escape. cavif --speed 9 (o cpu-used 9 en libavif) llega a estar a 3× de libwebp al precio de archivos un 5–8 % más grandes. Y caché agresivo: un pipeline de assets direccionados por contenido que evita recodificar fuentes sin cambios convierte un códec lento en un coste de una sola vez.

2.3 Profundidad de color y HDR

JPEG y WebP llegan como tope a sRGB de 8 bits. AVIF maneja color de 10 y 12 bits, Rec. 2020, DCI-P3 y funciones de transferencia PQ/HLG de forma nativa. Para miniaturas de vídeo HDR, galerías de fotografía profesional o pruebas de impresión en navegador, AVIF es hoy la única opción estandarizada disponible.

2.4 Transparencia y animación

JPEG no tiene ninguna de las dos. WebP y AVIF soportan canal alfa y animación. Cuando hablamos de reemplazar PNG transparente, AVIF codifica el alfa de forma más compacta: una ilustración de UI que se reduce un 30–40 % como WebP suele reducirse un 50–70 % como AVIF.

3. Árbol de decisión: qué formato para cada trabajo

3.1 Sitios estáticos: blogs, páginas de marketing, documentación

AVIF principal, WebP de fallback, JPEG de seguridad. La codificación ocurre una sola vez en CI, así que el impuesto de 5–20× se paga en tiempo de build, no en tiempo de quien visita. Es el caso canónico para el patrón <picture> de tres source que verás en la sección 4.

3.2 Subidas de personas usuarias: avatares, UGC, adjuntos de formularios

Comprimir a WebP en el navegador y recodificar a AVIF de forma asíncrona en el servidor. Hoy canvas.toBlob('image/avif') solo funciona en Chrome 99+, así que AVIF no puede ser la ruta de subida. WebP comprime rápido en el navegador y ahorra ancho de banda en la propia subida.

Si quieres una comparación más profunda de las librerías client-side (Squoosh, browser-image-compression, Compressor.js) y cómo se combinan con Sharp o Imagemin del lado del servidor, consulta la guía compresión de imágenes: navegador vs Node.js que la acompaña. La elección de formato y el lugar de procesamiento son ortogonales; esta guía cubre el eje del formato.

3.3 HDR y fotografía de alta fidelidad

Solo AVIF. Hoy nada más en el stack web abierto soporta color de 10 o 12 bits. Sáltate el fallback para assets exclusivamente HDR, o asume que el fallback JPEG será SDR.

3.4 Audiencias con peso de navegadores legados

JPEG principal, WebP opcional, sin AVIF. Portales gubernamentales, ciertos entornos empresariales del este de Asia y herramientas B2B con colas largas de dispositivos a veces muestran un 5–10 % de tráfico desde IE o Edge antiguo en analítica. WebP ya es seguro; AVIF todavía no.

3.5 Entrega en CDN en tiempo real

libvips o Sharp del lado del servidor sirviendo WebP en streaming, con AVIF generado en un worker en segundo plano y servido al haber cache hit. No bloquees la respuesta por la codificación AVIF. Cloudflare Polish, Vercel Image Optimization y Cloudinary f_auto automatizan ese patrón.

4. El fallback de `<picture>`, bien hecho

El elemento <picture> existe precisamente para que el navegador pueda elegir la mejor fuente soportada. Tres capas, con AVIF en primer lugar, te dan el presupuesto óptimo de bytes sin romperse en clientes antiguos.

4.1 La línea base de tres capas

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Paisaje de montaña al atardecer"
       loading="lazy" decoding="async" />
</picture>

Tres detalles importantes. El navegador recorre los elementos <source> de arriba abajo y elige el primero cuyo type entiende; el resto se ignora, no se descarga. La etiqueta <img> es el elemento que de hecho se renderiza y hereda atributos (alt, sizes, clases) sin importar qué fuente gane. Y width/height en el <img> no son opcionales en 2026: reservan espacio y previenen Cumulative Layout Shift.

Para imágenes above the fold, cambia loading="lazy" por loading="eager" fetchpriority="high". Hacer lazy-loading de la imagen LCP es uno de los tiros en el pie más comunes en Core Web Vitals.

4.2 Responsive más formato: el patrón completo

Cuando además necesitas resoluciones responsive, repite srcset dentro de cada <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Paisaje de montaña al atardecer"
       loading="lazy" decoding="async" />
</picture>

Sí, son nueve archivos generados por imagen. A esta escala, un paso de build no es negociable; la sección 5.3 cubre qué conectar.

4.3 Negociación `Accept` del lado del servidor como alternativa

Si tu CDN lo soporta, la negociación de contenido reduce el marcado a un único <img>. El navegador envía Accept: image/avif,image/webp,image/apng,*/* y el CDN responde con el mejor formato soportado en la misma URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto y CloudFront con Lambda@Edge implementan esto. La contrapartida: HTML más pequeño y una URL por imagen, pero lock-in con el CDN y depuración local más complicada. Una división útil es negociación en CDN para páginas de marketing y <picture> explícito para la UI del producto, donde importa el comportamiento determinista.

5. Cómo convertir imágenes entre formatos

5.1 En el navegador, sin subir nada

El camino más rápido para una conversión puntual o un lote pequeño es hacerlo solo en el navegador. Suelta un JPEG en el compresor de imágenes gratuito, elige WebP o AVIF como salida y el archivo nunca sale de tu computadora. La entrada AVIF está soportada en todas partes; la salida AVIF usa codificación nativa del navegador en Chrome 85+ y cae de forma transparente a WebP en navegadores que todavía no pueden codificar AVIF.

5.2 Línea de comandos para pipelines de build

Para un pipeline de producción quieres salida determinista y builds reproducibles. Estos tres comandos son reales:

# AVIF: cavif (Rust, instalación fácil con cargo o brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (libwebp oficial de Google)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Ambos, además de redimensionar, vía libvips (lo más rápido para lotes)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed va de 0 (más lento, más pequeño) a 10 (más rápido, más grande). El valor por defecto 4 es el punto óptimo para builds nocturnos; súbelo a 9 para previews de PR donde la velocidad pesa más que los bytes.

5.3 Integración con el pipeline de build

La mayoría de frameworks de sitios estáticos ya envuelven estos codificadores. Elige el que encaje con tu stack:

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programático — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Para assets diminutos (iconos por debajo de unos 5 KB, avatares inline, encabezados de email), sáltate la red por completo e inserta como data URI con codificación Base64. Cambias una petición HTTP por unos pocos bytes adicionales de HTML, normalmente conviene por debajo de los ~5 KB.

Si estás eligiendo entre librerías de compresión client-side y del lado de Node (Sharp vs Squoosh vs browser-image-compression), la guía compresión de imágenes: navegador vs Node.js entra en benchmarks y compromisos.

6. Trampas y malentendidos

6.1 “AVIF siempre gana”: no para capturas de pantalla ni line art

Las fortalezas de AVIF están en fotografías de tono continuo. En capturas con texto nítido, capturas de UI y pixel art, WebP suele producir archivos más pequeños con calidad equivalente. El deblocking de AVIF puede introducir banding sutil en regiones de color plano. Haz la conversión de las dos formas y elige el ganador por clase de asset.

6.2 “WebP sin pérdida reemplaza perfectamente a PNG transparente”: casi, no del todo

WebP sin pérdida es genuinamente más pequeño que PNG, normalmente alrededor de un 26 %. La trampa: el “sin pérdida” aplica a la imagen comprimida, pero el codificador todavía puede alterar el redondeo del canal alfa en regiones con gradientes pronunciados. Para reproducción exacta a nivel de píxel (imágenes médicas, assets de archivo, cualquier cosa que legalmente tenga que coincidir con la fuente), conserva PNG. Para el resto, WebP sin pérdida es ganancia neta.

6.3 “Solo sube los archivos .avif”: tu CDN puede no saber qué son

Las configuraciones antiguas de nginx y Apache son anteriores a AVIF. Si /etc/nginx/mime.types no incluye image/avif avif;, nginx sirve el AVIF como application/octet-stream. El navegador ve el Content-Type incorrecto, se niega a renderizar la imagen y cae al JPEG sin avisar, anulando toda la optimización. Haz curl a la URL del asset después del despliegue y revisa la cabecera Content-Type. Cinco segundos de paranoia ahorran una semana de “¿por qué AVIF está roto en producción?“.

6.4 El crash de AVIF en iOS 16.0–16.3

Algunos archivos AVIF disparan un crash en la decodificación de Safari en iOS 16.0–16.3. El bug está corregido en 16.4 (marzo de 2023), pero MDM empresarial y actualizaciones lentas de OEM mantienen vivos a los dispositivos antiguos. La mitigación: nunca envíes AVIF sin un <source> WebP funcional dentro del mismo <picture>, y nunca pongas un AVIF como src de <img> directamente. Si sigues los patrones de la sección 4 ya estás protegido.

7. La hoja de trucos para 2026

Escenario	Principal	Fallback	Codificador
Páginas de marketing estáticas	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp en CI
Posts de blog y documentación	WebP q75	JPEG q80	compresor de imágenes gratuito (manual) o Sharp (build)
Subidas de personas usuarias	WebP (client-side)	JPEG (navegador sin codificación WebP)	browser-image-compression + Sharp del lado del servidor para AVIF
HDR / fotografía profesional	AVIF 10-bit q70	(ninguno: descarta el fallback SDR o sáltate AVIF por completo)	cavif + libavif en modo HEIF
Entrega en CDN en tiempo real	Negociado (AVIF o WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Dos recordatorios antes de hacer ship. Pon siempre width y height en el <img> para evitar CLS. Verifica siempre la cabecera Content-Type en producción al menos en una respuesta AVIF; una configuración de MIME rota mata sin avisar a AVIF en producción, y lo hace más a menudo que cualquier otro fallo de esta lista.

Preguntas frecuentes

¿Sigo necesitando un fallback JPEG en 2026?

Sí. AVIF llega a aproximadamente el 93 % de las personas usuarias globales y WebP a alrededor del 97 %. Eso deja una población pequeña pero real (Edge antiguo, Firefox por debajo de 93, iOS anterior a 16.4 y la zona del bug iOS 16.0–16.3) que necesita JPEG. Quita JPEG solo si tu analítica muestra prácticamente cero tráfico desde esos navegadores y puedes demostrarlo.

¿Cómo mantengo rápidos los builds de CI cuando la codificación AVIF es lenta?

Hay tres palancas. Usa cavif --speed 6 o superior (por defecto está en 4) para cambiar ~5 % de tamaño por ~3× de velocidad. Paraleliza por núcleos con GNU parallel o el pool de workers de tu herramienta de build. Y cachea por hash de contenido para que las imágenes fuente sin cambios se salten el codificador por completo. Combinadas, estas técnicas suelen recortar el tiempo de build de AVIF por debajo de la línea base mono-hilo de WebP de antaño.

¿De verdad WebP decodifica más rápido que AVIF?

Sí. libwebp decodifica entre 2× y 3× más rápido que libavif, y la brecha se ensancha en móviles de gama baja. Si tu cuello de botella de rendimiento es la decodificación (por ejemplo, una galería larga de imágenes en un Android de bajo coste) y no la red, WebP es el mejor formato principal. Para la mayoría del tráfico web manda el ahorro de red, así que AVIF sigue ganando en general.

¿Pueden los iPhones ver AVIF?

Los iPhones con iOS 16.4 (marzo de 2023) o posterior soportan AVIF de forma nativa en Safari. Los dispositivos en iOS 16.0–16.3 tienen un bug de decodificación documentado que puede crashear Safari con ciertos archivos AVIF; las versiones de iOS anteriores no soportan AVIF en absoluto. Envía siempre un fallback WebP o JPEG dentro de <picture> para que las personas afectadas vean algo.

¿Debería usar `<picture>` o negociación con cabecera Accept?

Los proyectos más pequeños se benefician del marcado <picture> explícito: el comportamiento es determinista, puedes depurar localmente y añade quizá 80 bytes de HTML por imagen. Los sitios de alto tráfico ganan con la negociación Accept del lado del CDN: una URL por imagen, upgrades automáticos de formato y el CDN cachea cada formato por separado. Una solución híbrida frecuente es <picture> para la UI de la app y negociación en CDN para los assets de marketing.

¿Por qué mi PNG se hizo más grande al convertirlo a WebP?

Casi siempre porque el PNG fuente ya estaba agresivamente optimizado por pngquant, oxipng o ZopfliPNG, y el codificador basado en Canvas del navegador no puede igualar a esas herramientas. Recodifica desde el original (export de Photoshop, master de la herramienta de diseño, RAW) en lugar de hacerlo desde el PNG optimizado. Si el PNG optimizado es tu única fuente, el original ya está cerca del óptimo: déjalo como está.

¿AVIF soporta transparencia?

Sí. AVIF soporta un canal alfa completo de 8 a 12 bits, y su codificación de alfa es por lo general más compacta que la de WebP. Una ilustración PNG transparente convertida a AVIF se reduce un 50–70 %, frente al 30–40 % como WebP. AVIF es el reemplazo más fuerte para PNG transparente en cualquier contexto que no exija salida sin pérdida exacta a nivel de píxel.

¿Pueden los navegadores codificar AVIF de forma nativa con `toBlob('image/avif')`?

Solo Chrome 99+ por ahora. Safari y Firefox pueden decodificar AVIF, pero no pueden codificarlo mediante APIs de Canvas a fecha de mayo de 2026. Para codificación AVIF del lado del cliente actualmente necesitas librerías WebAssembly como libavif-wasm o jsquash, que añaden 1–2 MB de payload. La mayoría de los stacks en producción comprimen a WebP en el navegador y delegan la generación de AVIF a un worker en el servidor.