Chrome 155 activa JPEG XL con decoder en Rust

El navegador más usado del mundo por fin adopta JPEG XL

Chrome 155, cuyo despliegue gradual en escritorio y Android arrancó a principios de octubre de 2026 según Piunika Web, ya decodifica imágenes JPEG XL de forma nativa. La versión llegó de forma amplia a iOS primero y se está extendiendo al resto de plataformas en los días posteriores al anuncio.

Se trata de un giro relevante para cualquier equipo que gestione assets digitales: el navegador con mayor cuota de mercado del planeta por fin entiende un formato que, hasta ahora, solo estaba disponible de forma nativa en el ecosistema Apple, en Adobe Camera Raw / Lightroom Classic y en los Galaxy de Samsung, según el seguimiento de PetaPixel.

¿Qué aporta JPEG XL frente a JPEG y AVIF?

JPEG XL es el estándar ISO/IEC 18181 para imágenes de nueva generación, libre de regalías y nacido específicamente para sustituir al JPEG original de 1992, según recoge TechSpot. El propio equipo de Chrome recomienda probar tanto AVIF como JPEG XL y quedarse con lo que mejor funcione para cada caso, no tratar al nuevo formato como un reemplazo universal.

Las cifras que destaca el equipo de Chrome en su blog de desarrolladores son claras:

• 30–50% mejor compresión que JPEG a igual calidad visual.
• Compresión sin pérdida (lossless) disponible en el mismo formato.
• HDR nativo, sin tener que recurrir a contenedores externos como hace Apple con DNG en el iPhone 16 Pro.
• Transcoding JPEG → JPEG XL sin pérdida, ideal para migrar catálogos legacy sin recalcular nada.
• Soporte de 32 bits por canal, espacios RGB y CMYK, multi-frame y animaciones.

Apple, que según PetaPixel lleva más de un año dando soporte a JPEG XL en Finder, Preview, Safari, Photos y Final Cut, estima que un JPEG de 32 MB se queda en 24 MB en JPEG XL sin pérdida y en torno a 5 MB en JPEG XL perceptualmente sin pérdida.

El equipo de Chrome reconoce que JPEG XL brilla especialmente en compresión de alta fidelidad o sin pérdida, sobre todo en fotografía, y cuando se quiere decodificación progresiva granular, es decir, ir mostrando la imagen a resoluciones crecientes mientras se descarga.

Por qué el equipo de Chrome reescribió el decoder en Rust

Los decoders de imagen son una de las superficies de ataque más críticas de cualquier navegador moderno: procesan binarios no confiables directamente desde la red y corren dentro del proceso de renderizado. Históricamente, los decoders escritos en C++ han sido foco de vulnerabilidades tipo out-of-bounds reads, heap overflows y use-after-free.

El equipo de Chrome explica que, en lugar de seguir parchando el decoder histórico, integró jxl-rs, una implementación pura en Rust del decoder de JPEG XL. Para que el rendimiento no se resintiera, tuvieron que estabilizar la feature de Rust target_feature_11, que permite usar instrucciones SIMD sin escribir código unsafe.

Sobre esa base construyeron jxl_simd, una capa de abstracción SIMD inspirada en la biblioteca C++ Highway, que a su vez se creó originalmente para libjxl, la implementación de referencia del formato. El resultado, según el blog de Chrome, es una biblioteca multiplataforma con optimizaciones SIMD agresivas, pero con el código inseguro restringido a un número muy pequeño de localizaciones minuciosamente revisadas.

Para validar la implementación usaron fuzzing y revisión de código asistida por IA. A lo largo de toda la historia del decoder en Rust, no han encontrado ni un solo bug de seguridad de memoria, según reporta el equipo de Chrome.

Una década de idas y vueltas hasta llegar aquí

El camino hasta este anuncio no ha sido recto. Como recuerda TechSpot, JPEG XL fue la propuesta más popular entre los participantes del Interop 2024, el proyecto que agrupa a Chromium, Gecko (Firefox) y WebKit (Safari) para priorizar tecnologías web comunes. Aun así, la propuesta fue rechazada porque los miembros del proyecto no lograron consenso. Tras la decepción, Google deprecó el soporte experimental de JPEG XL en Chromium, argumentando que el ecosistema web no mostraba suficiente interés.

La presión sostenida de la comunidad y la decisión de Firefox de habilitar JPEG XL en su versión 157, según Piunika Web, parecen haber movido la aguja. El equipo de Chrome reconoce que la decisión de implementar JPEG XL se apoyó en feedback consistente de developers a través de bugs, encuestas, el Developer Signals Project y el Interop Project, y participó en la Interop 2026 JPEG XL Investigation para asegurar cobertura de tests para todas las features del formato en navegadores.

Qué significa esto para tu startup

Para un equipo que hoy está construyendo un producto web, la pregunta ya no es "si uso AVIF". Es "¿en qué situaciones me conviene JPEG XL en lugar de AVIF, y cómo empiezo a meterlo en mi pipeline sin romper a los usuarios que todavía no actualizaron Chrome?".

Acciones concretas que puedes tomar esta semana:

• Audita tu catálogo de imágenes y detecta candidatas a JPEG XL. Arranca por las fotos de producto y los assets fotográficos de alta fidelidad: ahí es donde el 30–50% de ahorro en peso se nota de verdad en LCP y en transferencia mensual. Para gráficos con paletas limitadas, AVIF probablemente siga siendo mejor opción.
• Implementa negociación por <picture> o por extensión. Chrome 155 ya entiende .jxl, Firefox 157 también, y Safari ya lo soportaba. Si sirves <picture> con <source type="image/jxl"> y un fallback a JPEG o AVIF, los usuarios con soporte verán el JPEG XL y el resto seguirá viendo el formato anterior. Eso te permite desplegar el cambio de forma progresiva, sin una migración big-bang.
• Mide antes de migrar todo de golpe. El equipo de Chrome recomienda probar ambos formatos por suite con tus imágenes reales y quedarte con lo que dé mejores resultados en tu caso. No es un "JPEG XL reemplaza a AVIF", es un nuevo formato que viene a coexistir y a cubrir huecos que AVIF no cubre bien, sobre todo en fotografía y lossless.

Lo que cambia de fondo: por primera vez en años, el navegador más usado del mundo se suma a un estándar que la industria fotográfica y herramientas como Adobe Lightroom ya habían abrazado. Para founders que trabajan con catálogos grandes de imágenes, e-commerce o medios digitales, la pregunta ya no es si JPEG XL va a ser parte del stack web, sino cuándo empiezas a sacarle ventaja competitiva en coste de almacenamiento y velocidad de carga.

Fuentes

• Shipping JPEG XL in Chrome
• Google begins gradual Chrome 155 rollout on desktop and Android; iOS gets wide release
• Google is once again accused of snubbing the JPEG XL image format
• Why Apple Uses JPEG XL in the iPhone 16 and What it Means for Your Photos