Chrome 155 activa JPEG XL por defecto

Chrome 155 decodifica imágenes JPEG XL por defecto, anunció el equipo de Chrome de Google el 6 de octubre de 2026. El decodificador es jxl-rs y está escrito en Rust por la seguridad de la memoria. Como Firefox 158 debe seguirlo el 13 de octubre, JPEG XL está a punto de funcionar en todos los grandes motores de navegador. Eso pone fin a un desvío de cuatro años para un formato que los desarrolladores web no dejaban de pedir.

Lo que Chrome ha lanzado

JPEG XL, con extensión de archivo .jxl, es un formato de imagen diseñado para sustituir a JPEG. Puede guardar fotos con tamaños más pequeños y también puede reempaquetar un JPEG existente sin perder nada de calidad.

El equipo de Chrome enumera las funciones que admite:

• compresión con y sin pérdida
• HDR, o alto rango dinámico, para luces más brillantes y sombras más profundas
• transcodificación JPEG sin pérdida, que reduce un JPEG antiguo y puede devolverlo al original exacto
• decodificación progresiva, que muestra primero una versión aproximada de la imagen y la va afinando a medida que llegan más datos
• animación

Según CoreWebVitals.io, el formato llegó por primera vez a Chrome 145 en febrero de 2026, tras un flag en chrome://flags/#enable-jxl-image-format. Chrome 155 elimina la necesidad del flag.

Por qué el decodificador está escrito en Rust

Los decodificadores de imágenes son un objetivo clásico de los atacantes. Un error en el código que desempaqueta una imagen puede dejar que una imagen trampa se haga con el control de un navegador. El equipo de Chrome llama a los decodificadores «una de las superficies de ataque más críticas y más atacadas de cualquier navegador web moderno».

Por eso eligió jxl-rs, un decodificador escrito desde cero en Rust. El compilador de Rust bloquea clases enteras de errores de memoria que C y C++ permiten. El equipo también creó jxl_simd, una capa SIMD inspirada en la biblioteca Highway de Google. Las instrucciones SIMD permiten que un procesador trabaje con muchos píxeles a la vez, lo que mantiene rápido el código seguro.

El equipo de Chrome dice que el fuzzing y la revisión de código con IA no encontraron errores de seguridad de memoria durante el trabajo. El fuzzing consiste en lanzar millones de entradas aleatorias contra el código.

Los informes discrepan sobre la velocidad. CoreWebVitals.io dice que jxl-rs funciona dentro del 15-25 % del decodificador de referencia en C++. Fileza sitúa la diferencia en el 5-10 %.

Por qué Chrome cambió de opinión

Chrome ya había retirado JPEG XL antes. Fileza la llama «la polémica retirada de 2022». El equipo de Chrome dice ahora que actuó por «comentarios y peticiones constantes de los desarrolladores web». Señala la popularidad del formato en las propuestas del Interop Project, donde los fabricantes de navegadores acuerdan cada año las carencias que corregirán juntos.

La vuelta sigue un largo hilo. Mozilla anunció en agosto la compatibilidad con JPEG XL con su propio decodificador en Rust. jpegxl.info ahora indica que Firefox 158 lo activará por defecto, previsto para el 13 de octubre de 2026.

Navegador	Estado de JPEG XL	Fuente
Chrome 155+	Activado por defecto	Equipo de Chrome, jpegxl.info
Chrome 145-154	Tras un flag	CoreWebVitals.io
Firefox 158	Activado por defecto, previsto para el 13 de octubre de 2026	jpegxl.info
Safari 17+	Compatible desde septiembre de 2023, sin animación ni decodificación progresiva	CoreWebVitals.io
Brave Beta 1.98+	Compatible, basado en Chromium 155	jpegxl.info

Cuánto más pequeños son los archivos

Las cifras sobre el tamaño varían. CoreWebVitals.io dice que los archivos JPEG XL son un 50-60 % más pequeños que JPEG y un 10-15 % más pequeños que AVIF. Tanto esa fuente como Fileza sitúan la recompresión JPEG sin pérdida en un 20 % menos aproximadamente.

No todos están de acuerdo con esas comparaciones. Una crítica detallada de septiembre sostenía que AVIF ya supera a JPEG XL en compresión. Mida con sus propias imágenes antes de elegir un ganador.

Qué significa esto para los desarrolladores

• Sirva JPEG XL con una alternativa. Use el elemento HTML picture con una fuente de tipo image/jxl, o compruebe la cabecera Accept en el servidor. Chrome anterior a la versión 155 y otros navegadores sin compatibilidad siguen necesitando JPEG, WebP o AVIF.
• Empiece por la recompresión JPEG sin pérdida. Es la ganancia más segura. Los JPEG existentes se reducen en torno a un 20 % y pueden devolverse al original exacto, así que no se pierde nada si cambia de opinión.
• Pruebe la animación y las imágenes progresivas en Safari. Según CoreWebVitals.io, Safari carece de ambas. Un JXL progresivo que se ve bien en Chrome puede cargarse de golpe allí.
• Actualice su cadena de imágenes. Los CDN, los redimensionadores y los validadores de subida que rechazan tipos MIME desconocidos bloquearán los archivos .jxl. Compruébelos antes de que los usuarios empiecen a subir archivos.
• Vigile Largest Contentful Paint. Las imágenes principales más pequeñas pueden mejorar esta puntuación de Core Web Vitals, que mide cuándo aparece el contenido principal. Compare antes y después con tráfico real, no solo en una prueba de laboratorio.

Siga el lanzamiento de Firefox 158 el 13 de octubre. Si llega según lo previsto, JPEG XL pasa a ser un formato con el que se puede planificar, en lugar de un experimento.