Crítica a JPEG XL: AVIF ya comprime mejor

Gianni Rosato publicó el 13 de septiembre de 2026 una crítica técnica detallada de JPEG XL. Sostiene que los codificadores AVIF actuales ya superan a JPEG XL en todo el rango de calidad. El momento importa para quien publica imágenes en la web, porque Firefox 157 activará JPEG XL por defecto a finales de septiembre.

JPEG XL es un formato de imagen normalizado en 2022 como ISO/IEC 18181. AVIF es el formato rival, construido sobre el códec de vídeo AV1. Ambos buscan archivos más pequeños que JPEG con la misma calidad visible.

Conviene saber una cosa antes de los números: Rosato trabaja en el formato rival. Escribe que se dedica a la compresión de imágenes, y que "trabajando en un codificador AV1, Julio Barba y yo hicimos avanzar notablemente AVIF". Lo declara en el propio artículo. Eso no vuelve falsas sus mediciones. Sí significa que ninguna parte independiente las ha comprobado todavía.

Qué afirma el artículo

Rosato empieza reconociendo los méritos del formato. "JPEG XL es un códec de imagen técnicamente impresionante; es una mejora clara sobre JPEG", escribe. Su crítica va contra JPEG XL comparado con AVIF, no comparado con JPEG.

En compresión sin pérdida mide JPEG XL alrededor de un 11,9 % más pequeño que WebP sin pérdida en contenido web realista. Lo considera un retorno escaso para el trabajo que exige el formato. En compresión con pérdida informa de que los codificadores AVIF actuales puntúan mejor en tres métricas perceptuales: CVVDP, MS-SSIM y SSIMULACRA2. Esas métricas estiman cuánto se parecen dos imágenes para una persona, en lugar de contar píxeles cambiados. "AVIF domina ahora todo el rango de fidelidad", escribe.

También nombra herramientas de compresión que JPEG XL no tiene. No hay modos de predicción direccional ni filtro de desbloqueo en bucle. La predicción direccional permite al codificador predecir un bloque de píxeles a partir de sus vecinos siguiendo un ángulo, lo que ayuda en los bordes duros. Un filtro de desbloqueo suaviza las costuras visibles entre bloques comprimidos. Que falten ambos limita al formato en imágenes no fotográficas, como capturas de pantalla y dibujos de línea, según él.

La bomba de decodificación

La afirmación más afilada es sobre el tiempo de decodificación, no sobre el tamaño. Rosato describe una imagen construida a propósito, a la que llama prime wall. Pesa 1.918 bytes, y su decodificación tardó 17,43 segundos de tiempo de usuario en un M5 Pro. Escribe que "la imagen prime wall pesa solo 1.918 bytes, así que va a resultar trivial bombardear con JXL los dispositivos de gama baja".

Esa es la forma de una denegación de servicio, no una queja de calidad. Una subida de dos kilobytes que cuesta segundos de CPU es un problema para cualquier servicio que decodifique imágenes enviadas por usuarios. Atribuye la brecha a lo expresiva que es la especificación de JPEG XL. Algunas construcciones son válidas y a la vez extremadamente lentas.

Informa de dos hallazgos más sobre la decodificación. En sus pruebas, WebP decodifica más de 10 veces más rápido que JPEG XL. El renderizado progresivo ya funciona también en AVIF, y era una de las ventajas restantes más claras de JPEG XL.

Los dos lados miden contra referencias distintas

El trabajo del propio proyecto JPEG XL complica el cuadro de la velocidad. jxl-rs es el decodificador en Rust que el proyecto dice que se distribuye tanto en Chrome como en Firefox. Su repositorio describe el objetivo: conformidad completa con la especificación, con mejor seguridad de memoria y mejor rendimiento de decodificación que libjxl, el software de referencia oficial en C++. El proyecto afirma que jxl-rs iguala de cerca esa referencia y a veces la supera, con menor uso de memoria.

Esas afirmaciones y las de Rosato no chocan de frente. Él mide JPEG XL contra WebP y AVIF. El proyecto mide su nuevo decodificador en Rust contra su propio decodificador en C++ anterior. Un decodificador puede ganar a su predecesor y aun así perder contra WebP. Leídas juntas, ambas describen un progreso real en la decodificación que todavía no ha cerrado la diferencia que informa Rosato.

Qué significa esto para los desarrolladores

No cambie de formato por un solo artículo. Cada cifra de arriba sale del conjunto de pruebas de un único autor, y ese autor trabaja en el formato que gana su comparación. La respuesta correcta es medir sus propias imágenes, porque los resultados de compresión varían mucho con el contenido.

Tres cosas merecen la pena este mes. Primero, codifique una muestra real de sus imágenes de producción en AVIF y en JPEG XL, y anote los tamaños con una calidad que de verdad publicaría. Segundo, mida los tiempos de decodificación en un teléfono barato y no en su portátil. Tercero, si acepta subidas de imágenes, ponga un límite duro de tiempo y de memoria a la decodificación, y pruébelo con un archivo deliberadamente incómodo.

El tercer punto vale la pena publique JPEG XL o no. Prime wall es un ejemplo de JPEG XL, pero todo códec moderno tiene entradas patológicas. Una ruta de subida sin presupuesto de decodificación es el fallo de verdad.

Para la mayoría de los sitios, el consejo práctico apenas se ha movido desde el anuncio de Mozilla. Use AVIF para fotografías corrientes, y JPEG XL donde importe el renderizado progresivo de imágenes muy grandes. Lo que añade esta crítica es un motivo para volver a comprobar ese segundo caso, porque el soporte progresivo de AVIF ya no es el punto débil que era.