JPEG XL vence a WebP por apenas 11,9% en modo sin pérdida

Chrome rechazó JPEG XL en 2023, y en 2026 las métricas de compresión perceptual todavía respaldan esa decisión. Un nuevo decodificador escrito en Rust llegó, con distinto grado de soporte, a Firefox y a Chrome, lo que revivió el debate sobre si el códec merece un lugar en la Web.

El ingeniero de compresión Gianni Rosato, que contribuyó a mejoras del codificador de AVIF y hoy desarrolla su propio códec de video, publicó un análisis técnico que compara JPEG XL contra AVIF y WebP en los escenarios que realmente importan en producción. Este artículo resume esos hallazgos con ejemplos prácticos para quien hoy elige qué formato de imagen usar en su stack web.

TL;DR

• Chrome retiró el soporte experimental de JPEG XL en 2023 pese a ser un códec libre de regalías del JPEG Committee.
• Un decodificador de JPEG XL escrito en Rust llegó a Firefox y Chrome en 2026, lo que reduce el riesgo de bugs de memoria.
• En modo sin pérdida, JPEG XL es solo un 11,9% más chico que WebP sin pérdida, medido sobre un dataset poco realista para la Web.
• En compresión con pérdida, la mayoría del tráfico web real, JPEG XL pierde frente a AVIF según CVVDP, MS-SSIM y SSIMULACRA2.
• Los codificadores de referencia de AV1 y SVT-AV1 recibieron ajuste perceptual con pruebas subjetivas humanas; libjxl no llegó a ese nivel.
• JPEG XL no tiene predicción direccional en sus bloques VarDCT (de 2x2 a 256x256 píxeles), lo que le cuesta preservación de bordes.
• Las splines, la propuesta de JPEG XL para preservar bordes, no tienen todavía ninguna prueba de concepto funcional.
• JPEG XL carece de un filtro de desbloqueo real: solo tiene gaborish y EPF como aproximaciones parciales.

Qué pasó con JPEG XL

Chrome eliminó el soporte experimental de JPEG XL en 2023, pese a que el códec, desarrollado dentro del JPEG Committee, es libre de regalías y venía ganando atención de empresas grandes. La decisión generó controversia entre defensores del software libre, que vieron en JPEG XL una alternativa abierta frente al peso de Google en los códecs de imagen.

En 2026 apareció un decodificador de JPEG XL escrito en Rust que llegó, en distinta medida, a Firefox y a Chrome. La lógica detrás es simple: un decodificador escrito en un lenguaje con memoria segura reduce el riesgo de repetir el incidente de 2023 con WebP, cuando una vulnerabilidad crítica en la librería libwebp (CVE-2023-4863) obligó a parchear de emergencia a Chrome, Firefox y decenas de aplicaciones que dependían de esa librería, incluidos Signal y 1Password.

La pregunta que plantea Rosato es directa: ¿alcanza un decodificador más seguro para justificar traer JPEG XL de vuelta a los navegadores? Su respuesta, apoyada en métricas de compresión, es que no alcanza por sí solo.

CVE-2023-4863 en libwebp forzó parches de emergencia en 2023.

Contexto e historia

JPEG XL nació dentro del JPEG Committee, con Jon Sneyers y Jyrki Alakuijala como autores principales. Rosato aclara en su análisis que respeta el trabajo y la conducta pública de ambos, y que incluso apoyó la inclusión de JPEG XL en Interop 2024, la iniciativa de navegadores para unificar el soporte de funciones web. Su objetivo no es desacreditar a los autores, sino ofrecer una mirada empírica sobre el estado de la compresión de imágenes en 2026.

La discusión sobre JPEG XL siempre estuvo cargada de simbolismo. Para buena parte de la comunidad de software libre, el códec representaba una alternativa abierta frente al peso de Google en el ecosistema de formatos, donde WebP y AVIF cuentan con fuerte respaldo de la Alliance for Open Media. Ese simbolismo, según Rosato, no debería reemplazar el análisis técnico a la hora de decidir qué formato sirve a la Web.

Detalles técnicos y rendimiento de JPEG XL

JPEG XL divide una imagen en bloques VarDCT que van de 2x2 a 256x256 píxeles y los transforma en representaciones de frecuencia, un esquema con el mismo espíritu del JPEG clásico pero con bloques de tamaño variable. Lo que le falta, según el análisis, son modos de predicción direccional: la técnica que usan códecs como WebP y AVIF para predecir los píxeles de un bloque a partir de los bloques vecinos, restar esa predicción de los píxeles reales y transformar solo la diferencia. Esa técnica preserva mejor los bordes de una imagen.

La propuesta de JPEG XL para compensar esa carencia son las splines, curvas matemáticas pensadas para representar bordes. El problema está en el codificador: hace falta un algoritmo que detecte qué píxeles pueden representarse como spline y después decida, con optimización de tasa-distorsión, si conviene codificarlos así. Rosato señala que no existe todavía ninguna prueba de concepto que use splines para preservación de bordes, ni motivos para creer que superarían a la predicción direccional.

JPEG XL tampoco tiene un filtro de desbloqueo dedicado, la herramienta que elimina los artefactos visibles entre bloques adyacentes. En su lugar usa dos filtros parciales: gaborish, el equivalente más cercano que tiene JPEG XL al filtro de restauración de AV1, y EPF (edge-preserving filter), el filtro que intenta preservar bordes. Ninguno de los dos reemplaza por completo a un filtro de desbloqueo real.

CódecCuándo usarloVentajaLimitación

JPEG XLArchivo fotográfico sin pérdida, flujos profesionales~11,9% más chico que WebP sin pérdidaNo competitivo en compresión con pérdida; soporte de navegador limitado
AVIFFotos e ilustraciones web, la mayoría de los casos de usoMejor fidelidad por bit en compresión con pérdida (CVVDP, SSIMULACRA2)Codificación más lenta que JPEG clásico
WebPCompatibilidad amplia, animaciones simplesSoporte universal en navegadores desde hace añosPor debajo de AVIF en métricas perceptuales modernas

Las métricas respaldan esa brecha. CVVDP y SSIMULACRA2 son métricas perceptuales diseñadas para acercarse a cómo el ojo humano evalúa artefactos de compresión, más confiables que métricas clásicas como PSNR al comparar códecs modernos. El codificador de referencia de AV1 recibió ajuste perceptual basado en pruebas subjetivas controladas con personas, y SVT-AV1 ofrece modos de ajuste similares. libjxl, el codificador de referencia de JPEG XL, no llegó a ese nivel de ajuste, según Rosato, que usa el codificador experimental aperture-alpha de Halide Compression como referencia de cuánta distancia hay todavía por recorrer.

💭 Clave: no existe tal cosa como un benchmark de códec, solo un benchmark de codificador: el techo teórico de JPEG XL como formato podría ser más alto de lo que libjxl consigue hoy en la práctica.

flowchart LR
    A["Imagen original"] --> B["Bloques VarDCT (2x2 a 256x256 px)"]
    B --> C["Transformada de frecuencia"]
    C --> D["Filtros gaborish y EPF"]
    D --> E["Bitstream JPEG XL"]

Los bloques VarDCT de JPEG XL van de 2x2 a 256x256 píxeles.

Cómo probarlo

Comprobar esta diferencia no requiere más que una terminal. libjxl, la implementación de referencia de JPEG XL, incluye las herramientas cjxl (codificador) y djxl (decodificador).

# Windows (con Scoop)
scoop install libjxl

# macOS (con Homebrew)
brew install jpeg-xl

# Linux (Debian/Ubuntu)
sudo apt install libjxl-tools

Con esas herramientas instaladas en cualquiera de los tres sistemas, ya podés codificar y decodificar archivos JPEG XL desde la línea de comandos.

# Codificar una imagen PNG a JPEG XL sin perdida real
cjxl entrada.png salida.jxl --distance=0

# Decodificar de vuelta a PNG para comparar visualmente
djxl salida.jxl salida_decodificada.png

# Comparar tamaños de archivo
ls -la entrada.png salida.jxl

El flag --distance=0 activa el modo sin pérdida real de JPEG XL. Comparando ese resultado contra un WebP sin pérdida generado con cwebp -lossless entrada.png -o salida.webp podés verificar en tu propia imagen si la diferencia del 11,9% se sostiene.

El soporte de navegador todavía es inconsistente entre versiones. En Chrome, la bandera experimental aparece en chrome://flags buscando "jxl"; en Firefox, en about:config buscando image.jxl.enabled, aunque la disponibilidad de esa bandera varía según la versión y el canal (stable, beta, nightly). Antes de depender de JPEG XL en producción sin un formato de respaldo, conviene revisar la matriz de compatibilidad actualizada.

⚠️ Ojo: ningún navegador mayoritario soporta JPEG XL de forma estable y universal en 2026. Usarlo hoy en producción sin un <picture> con formatos de respaldo (AVIF, WebP) rompe la imagen para buena parte de los visitantes.

Impacto y análisis

Para la enorme mayoría del tráfico de imágenes en la Web (fotos de producto, banners, ilustraciones, fondos de página), lo que importa es la compresión con pérdida, no sin pérdida. Ahí JPEG XL no gana. La ventaja real del formato, ese 11,9% en modo sin pérdida, además se midió sobre un dataset poco representativo de la Web: fotos de 157 megapíxeles, ilustraciones de 10 megapíxeles y libros escaneados de 27 megapíxeles, muy por encima de lo que sirve cualquier sitio a un usuario final.

El argumento de seguridad tampoco alcanza por sí solo. Que el nuevo decodificador esté en Rust reduce el riesgo de una vulnerabilidad de memoria como la de libwebp en 2023, pero eso justifica un decodificador más seguro, no necesariamente la adopción masiva de un formato completo con toda su superficie de codificación y sus casos de uso.

Para desarrolladores en LATAM que hoy eligen formato de imagen para un sitio o una app, el consejo práctico es simple: AVIF para compresión con pérdida donde el navegador lo soporte, WebP como respaldo universal, y JPEG XL solo en flujos de trabajo específicos donde el sin pérdida importa: fotografía profesional, archivo digital, impresión. No como formato general de la Web.

Qué sigue

Halide Compression prepara Aperture, el nombre en código de su próximo codificador, cuyo binario de prueba (aperture-alpha) Rosato usa como referencia de cuánto le falta a libjxl para competir en la frontera de eficiencia perceptual. Si algún codificador de JPEG XL cierra esa brecha, la discusión sobre incluirlo en los navegadores podría reabrirse con otros argumentos.

Mientras tanto, el decodificador en Rust seguirá expandiéndose en Firefox y Chrome, lo que reduce el riesgo si más sitios empiezan a servir JPEG XL para casos puntuales, sin que eso implique una adopción general del formato para reemplazar a AVIF o a WebP.

📖 Resumen en Telegram: Ver resumen.

Probalo vos: instalá cjxl y djxl desde libjxl, codificá una imagen tuya sin pérdida y comparala contra un cwebp -lossless para ver si ese 11,9% se sostiene en tu propio caso.

Preguntas frecuentes

¿Chrome va a soportar JPEG XL de forma nativa en 2026?

No hay un compromiso oficial confirmado. Chrome mantiene el decodificador en Rust en distintas etapas según la versión, pero eso no equivale a soporte nativo estable para todos los usuarios. Conviene revisar la matriz de compatibilidad antes de depender del formato en producción.

¿JPEG XL es mejor que AVIF para fotos?

En compresión con pérdida, que es el caso de uso dominante en la Web, los análisis con métricas CVVDP, MS-SSIM y SSIMULACRA2 muestran a AVIF por delante. La ventaja de JPEG XL aparece solo en modo sin pérdida.

¿Qué es SSIMULACRA2?

Es una métrica de calidad perceptual de imágenes diseñada para acercarse a cómo el ojo humano evalúa artefactos de compresión, más precisa que métricas clásicas como PSNR para comparar códecs modernos.

¿Qué relación tiene esto con la vulnerabilidad de WebP de 2023?

En 2023, una falla crítica en la librería libwebp (CVE-2023-4863) afectó a Chrome, Firefox y decenas de aplicaciones. El nuevo interés en un decodificador de JPEG XL en Rust busca evitar que un bug similar en C o C++ vuelva a comprometer navegadores masivamente.

¿Debería usar JPEG XL en mi sitio web hoy?

Para el caso general (fotos de producto, banners, imágenes de blog) conviene priorizar AVIF con WebP como respaldo. JPEG XL tiene sentido en flujos de trabajo fotográficos o de archivo donde el modo sin pérdida es un requisito real.

¿Qué es libjxl?

Es la implementación de referencia de JPEG XL, que incluye las herramientas de línea de comandos cjxl (codificador) y djxl (decodificador), mantenida en GitHub.

Referencias

• The case against JPEG XL, de Gianni Rosato: el análisis técnico original que compara JPEG XL contra AVIF y WebP.
• Repositorio de libjxl en GitHub: implementación de referencia de JPEG XL, con las herramientas cjxl y djxl.
• JPEG XL en Wikipedia: historia y especificación general del formato.
• CVE-2023-4863 en el NVD: la vulnerabilidad de libwebp que expuso a Chrome, Firefox y otras aplicaciones en 2023.
• Guía de formatos de imagen en MDN: referencia de compatibilidad y uso de formatos de imagen en la Web.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.