JPEG XL vs AVIF: ¿Qué formato deberías usar en producción?

Para la entrega web en producción en 2026, usa AVIF: tiene aproximadamente un 93% de cobertura global en navegadores a mediados de 2026, además de soporte maduro en CDN, CMS y herramientas de compilación. JPEG XL es técnicamente el formato superior — codificación más rápida, lossless decididamente mejor, decodificación progresiva nativa — pero Chrome aún lo incluye detrás de un flag, lo que deja a JXL con aproximadamente un 15% de cobertura, toda ella a través de Safari, que caniuse clasifica como soporte parcial. Ese único hecho resuelve la cuestión para cualquier sitio público: hasta que Chrome habilite JXL por defecto, una pila de entrega JXL-first sirve AVIF o JPEG a la gran mayoría de tus usuarios de todas formas.

Este artículo aborda directamente el caso de decisión intermedia: ya sirves WebP o AVIF, conoces las limitaciones de JPEG y quieres una decisión justificable basada en la realidad actual de los navegadores, no en el evangelismo de formatos. Analiza cada criterio por separado — compresión, soporte de navegadores, coste de codificación, renderizado progresivo — te proporciona un snippet correcto de <picture> y te indica la señal específica que deberías vigilar para que la recomendación cambie.

Qué es realmente cada formato

AVIF y JPEG XL resuelven el mismo problema — imágenes más pequeñas con igual o mejor calidad — pero provienen de linajes de diseño opuestos. AVIF (AV1 Image File Format) fue introducido por la Alliance for Open Media en 2019 y deriva de la codificación intra de fotograma clave del códec de vídeo AV1, utilizado por servicios como YouTube y Netflix. JPEG XL (ISO/IEC 18181) fue diseñado específicamente como formato de imagen fija por el Joint Photographic Experts Group junto con Google y Cloudinary, y fue finalizado como estándar en 2022.

Esa diferencia de origen — AVIF derivado de un códec de vídeo, JPEG XL diseñado específicamente para imágenes fijas — explica la mayoría de las compensaciones que se describen a continuación. AVIF hereda la potente compresión fotográfica con pérdida de AV1 y su codificador intensivo en CPU. JPEG XL fue diseñado en torno a consideraciones específicas de imagen: decodificación progresiva, color de alta profundidad de bits, modos lossless y una característica que ningún otro formato moderno ofrece — la recompresión JPEG lossless. Un JPEG existente puede transcodificarse a JXL, reduciendo el tamaño del archivo en aproximadamente un 20%, y decodificarse de vuelta al JPEG original byte a byte. Esto convierte a JXL en el único formato viable para archivar grandes bibliotecas de JPEG sin pérdida de calidad — un criterio de decisión genuino, no una nota al pie.

Compresión: el ganador depende del contenido

AVIF gana en compresión fotográfica con pérdida a calidades bajas y medias; JPEG XL gana a alta calidad, en contenido no fotográfico o de gráficos planos, y de forma decisiva en lossless. No existe una respuesta única del tipo “X es un N% más pequeño”, y cualquier artículo que te dé una está sobreestimando un resultado que depende del contenido.

El desglose práctico:

• Fotográfico con pérdida, calidad media: La pérdida de AVIF es más suave y natural a bitrates agresivos — difumina bordes y oculta artefactos donde el modo VarDCT de JPEG XL puede producir ringing o bloqueo similar al JPEG tradicional. Este es el terreno natural de AVIF y el caso web más habitual.
• Alta calidad y contenido no fotográfico: JPEG XL iguala o supera a AVIF, especialmente en ilustraciones, logotipos, capturas de pantalla y gráficos con mucho texto, donde su modo de codificación modular gestiona las regiones de color plano de forma limpia.
• Lossless: JPEG XL es decididamente mejor. El AVIF lossless es poco práctico — apenas mejora sobre PNG — mientras que el JXL lossless es competitivo con PNG y frecuentemente mucho más pequeño.

Las tasas de compresión varían significativamente según el contenido de la imagen y la configuración de calidad; la ventaja de JXL frente a AVIF en particular depende del contenido y no es un número establecido. Antes de comprometer una biblioteca de contenido a un formato, prueba tus activos específicos en Squoosh, que codifica ambos formatos en el navegador y muestra la relación tamaño/calidad para tus imágenes en lugar de los conjuntos de benchmarks de otros.

Soporte de navegadores: el eje decisivo

El soporte de navegadores es donde realmente se toma esta decisión, y es el eje que más artículos de referencia malinterpretan o reportan con información desactualizada. A mediados de 2026, AVIF tiene aproximadamente un 93% de cobertura global y está habilitado por defecto en Chrome, Edge, Firefox y Safari. JPEG XL se sitúa en aproximadamente un 15% de cobertura — toda ella a través de Safari, y clasificada como parcial.

El historial de Chrome importa porque dos de los tres artículos más citados lo reportan incorrectamente. La cronología exacta:

La afirmación ampliamente repetida de que Chrome “abandonó” JPEG XL está ahora desactualizada. Chromium revocó la designación obsoleta del formato y reintegró la decodificación utilizando un nuevo decodificador basado en Rust en lugar del libjxl en C++. Pero la reintegración no es lo mismo que el lanzamiento: en el canal estable actual, la decodificación JXL en Chrome permanece deshabilitada por defecto y requiere activación manual mediante chrome://flags/#enable-jxl-image-format. Firefox incluye código JXL en Nightly detrás de la preferencia image.jxl.enabled, pero no lo compila en las versiones de lanzamiento y no ha publicado ninguna fecha de entrega.

La traducción a una decisión de producción es la parte que todo artículo de referencia insinúa pero ninguno expresa con claridad: un elemento <picture> con JXL-first sirve hoy AVIF o JPEG a aproximadamente el 85% de tus usuarios. Codificas y almacenas tres variantes de formato para entregar JXL a aproximadamente uno de cada siete visitantes — y ese alcance es únicamente soporte parcial de Safari. Ese es el coste real de apostar por JXL-first ahora, y solo se amortiza cuando Chrome habilite el formato por defecto.

Coste de codificación y renderizado progresivo

JPEG XL codifica más rápido que AVIF y soporta de forma única la decodificación progresiva; la codificación AVIF es intensiva en CPU y no tiene un modo progresivo real. Ambas diferencias son operativamente relevantes — una en tu pipeline de compilación, otra en el tiempo de carga percibido por tus usuarios.

La codificación AVIF es el paso lento en la mayoría de los pipelines

La codificación AVIF con el codificador de referencia AV1 (libaom-av1) es la etapa más lenta en un pipeline de imágenes típico, materialmente más lenta por imagen que JPEG XL a calidad perceptual equivalente. Para una sola imagen hero convertida manualmente, esto es insignificante. Para un trabajo de CI que procesa cientos de imágenes de producto en cada despliegue, es una restricción real: el tiempo de codificación escala con el número de imágenes y el codificador AV1 es computacionalmente costoso por diseño.

Mitigaciones prácticas para un pipeline en Node.js:

• Usa Sharp, que envuelve libvips, para la codificación AVIF y JXL. Expone controles de quality y effort que intercambian tiempo de codificación por tamaño de salida.
• Ajusta el parámetro de esfuerzo/velocidad en lugar de ejecutar el codificador al máximo esfuerzo por defecto — la codificación AVIF de alto esfuerzo produce archivos marginalmente más pequeños a un gran coste de tiempo.
• Paraleliza entre hilos de trabajo o núcleos de CPU, o delega la conversión a una CDN que codifique al vuelo para que nunca bloquee tu compilación.

const sharp = require("sharp");

// AVIF: lower `effort` trades a little size for much faster CI encoding
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXL encodes faster at comparable quality (requires a libjxl-enabled build)
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

Comprueba tu instalación de sharp para verificar la disponibilidad de formatos con sharp.format — el soporte de JXL depende del libvips/libjxl incluido y no está garantizado en todas las distribuciones.

La decodificación progresiva afecta al LCP percibido

JPEG XL soporta decodificación progresiva nativa: el navegador renderiza una versión de baja calidad de la imagen de inmediato y la va mejorando a medida que llegan los datos. AVIF no tiene un modo progresivo real, por lo que una imagen AVIF grande o se pinta completamente o no se pinta en absoluto. En conexiones lentas, esto se manifiesta como un retraso visible en el Largest Contentful Paint — el espacio de la imagen hero permanece en blanco hasta que llega el archivo completo.

Esta es una clase de problema que vemos directamente en las repeticiones de sesión: en páginas con muchas imágenes, el espacio de la imagen hero permanece en blanco durante toda la descarga de una imagen grande en una conexión limitada, con la marca de tiempo del LCP fijada al momento en que el archivo completo finalmente se pinta. La decodificación progresiva al estilo JXL aborda exactamente ese fallo — una imagen de baja calidad que aparece pronto y se va mejorando — que es el comportamiento de rendimiento perceptual que importa para los usuarios reales en redes lentas, y la razón por la que el tamaño del payload y el renderizado progresivo son palancas del LCP, no preferencias cosméticas.

El marco de decisión: usa X si…

Usa AVIF ahora para producción web pública, con fallbacks de WebP y JPEG mediante <picture>. Recurre a JPEG XL en casos específicos y acotados: flujos de trabajo lossless o de archivo, bibliotecas de imágenes no fotográficas, audiencias concentradas en Safari o grandes archivos JPEG que quieras recomprimir sin pérdida de calidad.

Usa AVIF si:

• Gestionas un sitio de producción público que necesita amplia cobertura hoy.
• Tus activos son principalmente fotográficos o mixtos.
• Usas un CMS o CDN con soporte nativo — AVIF es nativo en WordPress desde WP 6.5 (abril de 2024), y las principales CDN lo codifican al vuelo.
• Quieres mejoras medibles en el LCP respecto a JPEG/WebP sin gestionar una cuarta variante de formato.

Recurre a JPEG XL si:

• Mantienes un gran archivo de JPEG y quieres recompresión lossless — transcodifica a JXL (~20% más pequeño) y reconstruye los originales byte a byte.
• Tu contenido es predominantemente no fotográfico: ilustraciones, logotipos, diagramas, capturas de pantalla.
• Tu audiencia es mayoritariamente de Safari y controlas el markup completo de <picture> en una configuración headless o personalizada.
• Estás construyendo una entrega con visión de futuro para el momento en que Chrome habilite JXL por defecto.

JPEG XL no tiene soporte nativo de carga en WordPress a mediados de 2026, lo que refuerza a AVIF como la opción práctica para CMS.

Un snippet correcto y actualizado de <picture>

En un elemento <picture>, el navegador evalúa las entradas <source> en el orden del documento y selecciona el primer type que soporta, recurriendo al <img> si ninguno coincide. El orden no es, por tanto, cosmético — es el algoritmo de selección. Lista los formatos de mejor a peor según tu prioridad, y haz que el fallback del <img> sea un JPEG con soporte universal, no WebP (WebP necesita su propia entrada <source> porque es un tipo MIME distinto).

<picture>
  <!-- JXL first: served only to Safari 17+ (partial); Chrome flagged-off in mid-2026 -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF: ~93% coverage, the workhorse tier for nearly all traffic -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: covers older Chrome/Firefox that predate AVIF -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: unconditional fallback; the src that always renders -->
  <img src="hero.jpg" alt="Description" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

La lectura honesta de esta pila de cuatro niveles: hoy te cuesta cuatro variantes codificadas para entregar JXL a una minoría exclusiva de Safari. Si tu audiencia no es mayoritariamente de Safari y no tienes razones de archivo para JXL, elimina el primer <source> y usa la versión de tres niveles AVIF/WebP/JPEG — cubre casi todo el tráfico con un formato menos que compilar y almacenar. Añade el source JXL cuando Chrome cambie el flag, no antes.

Qué vigilar para que la recomendación cambie

El desencadenante práctico para hacer de JPEG XL tu formato de entrega principal es que Chrome active chrome://flags/#enable-jxl-image-format por defecto; hasta que eso ocurra, la matemática de cobertura — aproximadamente 15% JXL (solo Safari, parcial) frente a ~93% AVIF — mantiene a AVIF como el único formato primario justificable para producción web pública. Señales concretas que vale la pena monitorizar:

• La entrada de Chrome Platform Status para JPEG XL cambiando de flagged a shipped/default-on.
• La cobertura de soporte completo de caniuse.com/jpegxl superando un umbral utilizable y perdiendo su designación de parcial.
• Firefox moviendo JXL de Nightly a una versión de lanzamiento.
• Las principales CDN habilitando la conversión JXL por defecto en sus pipelines de imágenes.

Cuando se produzca la primera de esas señales, una pila <picture> con JXL-first dejará de ser un coste especulativo y se convertirá en la recomendación por defecto, invirtiendo el marco anterior.

Conclusión

Usa AVIF hoy y mantén tu markup de <picture> listo para JPEG XL. AVIF es el formato que llega a tus usuarios ahora, con las herramientas y el soporte de CMS que lo respaldan; JPEG XL es el mejor formato en méritos técnicos y la herramienta adecuada para archivos lossless y recompresión JPEG, pero su caso para la web pública está condicionado enteramente a que Chrome lo habilite por defecto. Convierte tus activos a AVIF, añade fallbacks de WebP y JPEG, y vigila la entrada de Chrome Platform Status — el día que ese flag se active por defecto es el día de reconsiderar JXL como tu source principal.

Preguntas frecuentes

¿Servir AVIF y un source JXL en el mismo elemento picture duplica mi almacenamiento y ancho de banda?

Aumenta el almacenamiento pero no el ancho de banda por solicitud. Cada variante de formato que listes añade un archivo codificado que almacenar, por lo que una pila de cuatro niveles JXL, AVIF, WebP, JPEG implica cuatro archivos almacenados por imagen. El ancho de banda no se ve afectado porque el navegador descarga únicamente el primer source soportado que selecciona, nunca múltiples variantes. El coste real de una pila JXL-first es la codificación y el almacenamiento adicionales para llegar a una minoría exclusiva de Safari, no las descargas duplicadas.

¿Puedo convertir mis imágenes AVIF a JPEG XL más adelante sin recodificar desde el original?

No, no sin pérdida de calidad. La transcodificación lossless de JPEG XL es exclusiva de fuentes JPEG, no de AVIF o WebP. Puedes envolver un JPEG existente en JXL y reconstruirlo byte a byte, pero AVIF y WebP son formatos con pérdida sin esa ruta reversible. Convertir AVIF a JXL implica decodificar el AVIF ya comprimido y recodificarlo, acumulando artefactos. Conserva siempre tus masters originales lossless para poder recodificar a cualquier formato de forma limpia.

¿Por qué mi imagen hero en AVIF sigue perjudicando el Largest Contentful Paint aunque el archivo sea más pequeño que el JPEG?

AVIF no tiene decodificación progresiva real, por lo que una imagen AVIF grande solo se pinta una vez que llega el archivo completo, en lugar de renderizar primero una vista previa de baja calidad. En una conexión lenta, el espacio hero permanece en blanco durante toda la descarga, y la marca de tiempo del LCP queda fijada al pintado final. Un tamaño de archivo total menor no cambia este comportamiento de todo o nada. La decodificación progresiva de JPEG XL mejora incrementalmente, lo que mejora la carga percibida incluso con recuentos de bytes similares.

¿Un navegador que soporta tanto AVIF como JPEG XL elegirá el source que liste primero?

Sí. El elemento picture selecciona el primer source cuyo atributo type soporta el navegador, evaluado en el orden del documento, independientemente del tamaño del archivo o la capacidad del formato. Si listas JXL antes que AVIF, una versión de Safari que soporte ambos sirve JXL; invierte el orden y sirve AVIF. El navegador no compara calidad ni peso, por lo que el orden de los sources es el mecanismo de selección. Coloca tu formato preferido primero y termina con un fallback img en JPEG con soporte universal.