AVIF en 2026: el formato web del futuro (esta vez de verdad)

Qué es el AVIF, técnicamente

AVIF significa AV1 Image File Format. Es un formato de imagen basado en el códec de vídeo AV1, desarrollado a su vez por la Alliance for Open Media — un consorcio fundado en 2015 que reúne a Google, Netflix, Mozilla, Amazon, Microsoft, Apple, Meta e Intel. El objetivo inicial era crear un códec de vídeo de nueva generación libre de royalties (al contrario que HEVC/H.265) para el streaming en 4K y 8K.

La idea del AVIF nació de forma natural: si el AV1 comprime tan bien el vídeo, ¿por qué no usarlo para imágenes fijas? La especificación AVIF se finalizó en 2019, y los primeros soportes de navegadores llegaron en 2020 (Chrome 85). Desde entonces, la adopción ha sido progresiva y alcanzó su masa crítica en 2024-2025.

Técnicamente, el AVIF usa las herramientas de compresión espacial del AV1 (análisis por bloques, predicción intra-imagen, transformación y cuantificación adaptativas) sin las herramientas de compresión temporal (que no tienen sentido para una imagen fija). El resultado es un archivo de imagen que puede pesar hasta un 50 % menos que un JPG a calidad visual equivalente, soportando a la vez transparencia, HDR, wide color gamut e incluso imágenes animadas.

AVIF vs WebP vs JPG: el comparativo con cifras

Tomemos una foto estándar de 4000 × 2667 píxeles (resolución típica de una cámara digital de 12 megapíxeles) y exportémosla en los tres formatos a calidad 80:

— JPG: 1 240 KB de media. Legible en todas partes desde hace 30 años. Sin transparencia. — WebP: 720 KB (–42 % vs JPG). Legible por el 97 % de los navegadores en 2026. Soporta transparencia. — AVIF: 480 KB (–61 % vs JPG, –33 % vs WebP). Legible por el 94 % de los navegadores en 2026. Soporta transparencia + HDR + wide color.

La diferencia es aún más espectacular en gráficos con planos de color (logos, ilustraciones vectorizadas): un PNG transparente de 500 KB puede caer a 80 KB en WebP y bajar de los 50 KB en AVIF, sin ninguna diferencia visible.

En una página web típica con 20 imágenes de media, pasar de JPG a AVIF ahorra típicamente entre 8 y 12 MB de ancho de banda por visita, lo que se traduce en 1 a 2 segundos menos de LCP en móvil con 4G. Para un sitio con mucho tráfico, son también ahorros sustanciales en CDN: si pagas por petición (Cloudflare, Vercel, AWS), la factura mensual baja proporcionalmente.

La compatibilidad en 2026: ¿quién soporta AVIF?

Este es el estado de los soportes en 2026 (fuente caniuse.com, mayo de 2026):

Soporte completo: — Chrome (desde la v85, agosto 2020) y todos los navegadores Chromium (Edge, Opera, Brave, Vivaldi, Samsung Internet) — Firefox (desde la v93, octubre 2021) — Safari en macOS (desde la v16, septiembre 2022) y en iOS/iPadOS (desde la v16, septiembre 2022)

Soporte parcial o ausente: — Safari antiguos en iOS 15 y anteriores: sin soporte nativo. Con la extinción progresiva de estas versiones, estamos en torno al 3 % de usuarios afectados en 2026. — Navegadores in-app de redes sociales: en general actualizados, pero algunos van rezagados, sobre todo en el mercado chino. — Internet Explorer: cero soporte, pero da igual en 2026 (cuota de mercado < 0,5 %).

Total en 2026: alrededor del 94 % de los usuarios mundiales pueden ver un AVIF. Para el 6 % restante, servimos un fallback WebP o JPG vía la etiqueta HTML <picture>. La estrategia multiformato es ya estándar en todos los sitios profesionales.

Codificar a AVIF: 3 herramientas en 2026

Método 1 — PixFlow (lo más sencillo). Entra en pixflow.tech/es/convert-jpg-to-avif o pixflow.tech/es/convert-png-to-avif, arrastra tus archivos, ajusta la calidad (80 por defecto, el buen compromiso), descarga los AVIF. Procesamiento 100 % local en tu navegador, por lotes, gratis ilimitado. Ideal para uso puntual o preparación de catálogo.

Método 2 — Squoosh.app (Google Labs). Herramienta web gratuita de Google que ofrece comparativa visual entre formatos. Cargas una imagen, ves el JPG, el WebP y el AVIF lado a lado, ajustas la calidad con precisión y descargas. Excelente para entender el impacto de los parámetros de codificación. Más lento que PixFlow para el procesamiento por lotes.

Método 3 — Sharp / ImageMagick / FFmpeg en línea de comandos. Para pipelines de build CI/CD o transformaciones automatizadas en el servidor. Sharp (librería Node.js) se ha convertido en el estándar de facto para los frameworks JS modernos (Next.js, Astro, Eleventy) con optimización nativa de imágenes. ImageMagick sigue siendo útil para scripts batch sobre miles de imágenes. FFmpeg también sabe codificar AVIF, útil si también procesas vídeo.

El tiempo de codificación en AVIF es mayor que en WebP (típicamente 5 a 10 veces más según la calidad buscada), porque el algoritmo AV1 explora más opciones de compresión. Para cientos de imágenes, cuenta varios minutos en batch. Una vez codificado, el archivo final es más pequeño y de mejor calidad — se rentabiliza con el uso.

Servir AVIF en producción: la etiqueta <picture>

Una vez codificadas tus imágenes en varios formatos, el despliegue se hace vía la etiqueta HTML <picture>, que sirve automáticamente el formato óptimo según el navegador:

<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="..." loading="eager" fetchpriority="high" width="1920" height="1080"> </picture>

El orden es importante: el navegador prueba los <source> en orden y sirve el primero que sepa decodificar. Así que AVIF primero (el más moderno y ligero), WebP como respaldo, y JPG como último recurso para navegadores muy antiguos.

Acuérdate de añadir los atributos width / height en la etiqueta <img> para reservar el espacio y evitar el CLS, y fetchpriority='high' + loading='eager' para las imágenes críticas (hero, above the fold). Las imágenes más abajo en la página pueden quedarse en loading='lazy' (por defecto) para ahorrar ancho de banda.

Los frameworks modernos (Next.js Image, Astro Image, Eleventy Image, Nuxt Picture) automatizan todo este proceso: tú le das la imagen fuente, ellos generan las versiones AVIF/WebP/JPG a los tamaños correctos y producen la etiqueta <picture> en el build. Ganas en tiempo de desarrollo y en coherencia.

Los límites y trampas del AVIF en 2026

El AVIF no es magia. Aquí están las trampas que conviene conocer:

1. Codificación lenta. Convertir una carpeta de 500 fotos a AVIF lleva bastante más tiempo que a WebP. Para pipelines automatizados (CI/CD), puede alargar los builds. Mitigación: codificar en paralelo con tantos workers como núcleos de CPU.

2. No es el mejor formato para streaming progresivo. El JPG progressive permite mostrar una versión de baja resolución en cuanto llegan los primeros bytes, que se afina con el tiempo. El AVIF no tiene equivalente nativo — se muestra completo una vez descargado por entero. Para imágenes > 200 KB en conexión lenta, la experiencia de usuario puede ser menos fluida.

3. Herramientas de retoque tradicionales rezagadas. Photoshop añadió soporte AVIF en 2023 pero vía plugin de terceros. Lightroom Classic, Affinity Photo, GIMP: soporte desigual según versiones. Si quieres retocar AVIFs, quédate mejor en PNG/TIFF para el trabajo y exporta a AVIF solo al final.

4. Compatibilidad incompleta para navegadores in-app. Algunos navegadores integrados en apps móviles (versiones antiguas de Facebook, WeChat, etc.) aún no tienen soporte AVIF. Es para ese 6 % de usuarios para quienes el fallback WebP/JPG vía <picture> sigue siendo indispensable.

5. Codificación CPU-intensiva en los servidores. Si generas los AVIF al vuelo en el servidor (en lugar de pre-codificar en build), puede sobrecargar tus workers. Solución: pre-generar todas las variantes en build, o usar un servicio de CDN de imágenes (Cloudinary, Imgix, Vercel Images) que mutualiza el coste.