⏱️ Lectura: 10 min
Chrome empieza a leer archivos .jxl sin plugins: la versión 155 del navegador decodifica JPEG XL en Chrome de forma nativa, con un decodificador escrito desde cero en Rust. Google lo anunció el 6 de octubre de 2026 en el blog de Chrome for Developers, tras años de pedidos constantes de desarrolladores dentro del proceso de interoperabilidad web.
📑 En este artículo
La noticia no es solo un formato más en la lista de compatibilidad. Es la primera vez que Chrome suma un decodificador de imágenes completo construido en un lenguaje memory-safe, después de años de vulnerabilidades en decodificadores escritos en C++.
TL;DR
- Chrome 155 decodifica JPEG XL (.jxl) nativamente con un decodificador reescrito en Rust.
- JPEG XL comprime 30%-50% mejor que JPEG, con modo sin pérdida y transcodificación reversible.
- jxl-rs, el decodificador en Rust, evita lecturas fuera de límites y use-after-free del C++ anterior.
- Rust estabilizó target_feature_11 para usar SIMD sin código unsafe y no perder rendimiento frente a libjxl.
- Google impulsó Interop 2026 para blindar la cobertura de pruebas de JPEG XL en todos los navegadores.
Qué es JPEG XL en Chrome
JPEG XL es un formato de imagen de próxima generación diseñado por el comité JPEG para fotografía y contenido web. Comprime entre un 30% y un 50% mejor que JPEG, soporta compresión sin pérdida, HDR nativo y transcodificación reversible de archivos JPEG existentes sin perder calidad.
El formato lo impulsa un grupo reducido de ingenieros, entre ellos Luca Versari, Moritz Firsching y Philip Jägenstedt, autores del anuncio de Chrome. Su objetivo declarado es cubrir tanto la fotografía de alta fidelidad como las imágenes que hoy viven como JPEG en miles de millones de sitios.
Qué pasó
A partir de Chrome 155, cualquier sitio puede mostrar JPEG XL en Chrome de forma nativa, sin extensiones ni flags experimentales. Google aclara que, por ahora, el soporte cubre solo la decodificación: Chrome todavía no incluye un encoder para generar archivos .jxl desde el navegador.
El equipo recomienda a los desarrolladores probar tanto AVIF como JPEG XL antes de elegir un formato de producción. Según el anuncio, JPEG XL rinde mejor en compresión de alta fidelidad, imágenes sin pérdida y casos donde conviene una decodificación progresiva detallada, mientras AVIF sigue siendo una alternativa sólida para compresión general con pérdida.
La publicación detalla tres frentes de trabajo: la reescritura del decodificador en Rust por seguridad, el trabajo de rendimiento para igualar a la implementación de referencia en C++, y la participación de Chrome en el proceso de interoperabilidad web que terminó empujando el lanzamiento.
Contexto e historia
JPEG XL no es nuevo: el comité JPEG lo estandarizó como sucesor de JPEG pensando en reemplazar tanto la fotografía cotidiana como los flujos de trabajo profesionales que todavía dependen de TIFF o PNG para evitar pérdida de calidad. Chrome había probado el formato antes, detrás de una bandera experimental, y la retiró en 2022 sin dar continuidad inmediata, lo que generó una reacción fuerte entre desarrolladores y fotógrafos que ya lo habían adoptado.
Esa salida convirtió al formato en una de las propuestas más discutidas dentro del Project Interop, el proceso donde los navegadores acuerdan qué funciones priorizar para que la web funcione igual en todos lados. El anuncio de Chrome confirma que fue una propuesta popular en 2026 y en años anteriores dentro de ese proceso, algo que terminó pesando más que la resistencia inicial del equipo de Chrome.
El resultado es un historial poco común para un estándar web: pasó de tener soporte experimental, a ser removido, a volver cuatro años después con una implementación completamente nueva y un argumento de seguridad que no existía en la primera ronda.
Detalles técnicos
Los decodificadores de imágenes son una de las superficies de ataque más explotadas de cualquier navegador: procesan datos binarios complejos que llegan directo de la red y corren dentro del proceso que renderiza la página. Históricamente, los decodificadores en C++ sufrieron lecturas fuera de límites, desbordamientos de heap y errores de use-after-free, el tipo de bug que termina en una vulnerabilidad explotable.
Chrome ya aplica aislamiento de procesos como primera defensa, bajo lo que el equipo llama la regla de los dos: un componente que procesa datos no confiables, corre en sandbox y está escrito en un lenguaje no seguro para la memoria se considera de alto riesgo por diseño. jxl-rs elimina directamente la tercera condición, porque es una reimplementación completa del decodificador escrita en Rust, sin depender del sandbox como única barrera.
El problema de reescribir en Rust es que el rendimiento de un códec de imagen depende del uso intensivo de instrucciones SIMD del hardware, algo que tradicionalmente exige código unsafe. Para evitarlo, el equipo estabilizó la función target_feature_11 del lenguaje, que permite usar instrucciones SIMD sin bloques inseguros. Sobre esa base construyeron jxl_simd, una capa de abstracción inspirada en Highway, la misma biblioteca de C++ que originalmente se diseñó para libjxl, la implementación de referencia del formato.
Con esas dos piezas, jxl-rs reutiliza las optimizaciones de rendimiento de libjxl, incluida una canalización que minimiza las copias de datos entre regiones de la imagen durante el procesamiento. Google dice haber verificado la implementación con fuzzing y revisión de código asistida por IA, sin encontrar errores de seguridad de memoria en todo el historial del proyecto.
| Formato | Compresión con pérdida | Modo sin pérdida | HDR nativo | Transcodifica JPEG existente |
|---|---|---|---|---|
| JPEG | Base de comparación | No | No | – |
| AVIF | Mejor que JPEG, ya soportado en Chrome | Sí, pero poco usado | Sí (PQ/HLG) | No |
| JPEG XL | 30%-50% mejor que JPEG | Sí | Sí | Sí, sin pérdida |
flowchart TD
A["Servidor envia imagen .jxl"] --> B["Proceso de red de Chrome"]
B --> C["Proceso renderizador"]
C --> D["jxl-rs: decodificador en Rust"]
D --> E["Pixeles RGB o HDR"]
E --> F["Composicion en pantalla"]
subgraph Aislamiento
C
D
endLa combinación no es habitual: normalmente ganar seguridad de memoria significa resignar rendimiento, o mantener el rendimiento a costa de código unsafe disperso por todo el proyecto. jxl-rs apuesta a que una capa de abstracción bien diseñada evita ese dilema.
Impacto y análisis
El caso de jxl-rs se suma a una lista creciente de componentes críticos de Chrome reescritos en Rust, parte de una estrategia más amplia para reducir la proporción de vulnerabilidades de memoria que históricamente domina los reportes de seguridad del navegador. Un decodificador de imágenes nuevo, memory-safe y comparable en velocidad al original en C++ es exactamente el tipo de componente donde ese cambio de lenguaje rinde más, porque se ejecuta en todas las pestañas, con cualquier imagen de cualquier sitio.
Para desarrolladores, la llegada de JPEG XL en Chrome 155 reabre una decisión que llevaba años en pausa: qué formato de imagen usar en producción. El formato compite directamente con AVIF en compresión con pérdida, pero suma dos capacidades que AVIF no ofrece: transcodificación reversible de archivos JPEG existentes y un modo sin pérdida pensado para fotografía profesional.
💭 Clave: la transcodificación sin pérdida permite convertir un JPEG viejo a .jxl y recuperar el JPEG original byte a byte si hace falta, algo que ningún otro formato de imagen moderno ofrece hoy.
El límite real es la fragmentación entre navegadores. El soporte del códec .jxl en Firefox y Safari sigue siendo parcial o inexistente según el navegador, así que un sitio que sirva .jxl directo sin alternativa va a dejar sin imagen a una parte de sus visitantes. La recomendación práctica, tanto de Google como del uso habitual en la industria, es servir JPEG XL dentro de un elemento picture con un source de respaldo en AVIF o JPEG.
Qué sigue
Chrome participó en la investigación de Interop 2026 sobre JPEG XL específicamente para asegurar que exista cobertura de pruebas de todas las funciones del formato en los navegadores, y que esas pruebas pasen en Chrome. Eso sugiere que el objetivo de mediano plazo es presionar a otros motores para que sumen soporte equivalente, no solo que Chrome decodifique el formato en soledad.
Falta además la otra mitad del trabajo: un encoder nativo en el navegador o en las herramientas de build más comunes. Mientras tanto, la generación de archivos .jxl sigue dependiendo de herramientas de línea de comandos basadas en libjxl, lo que limita la adopción a equipos que ya automatizan su pipeline de imágenes.
Probalo vos: actualizá a Chrome 155 (o a un canary más reciente) y abrí un archivo .jxl directo en la barra de direcciones para ver el decodificador en Rust funcionando hoy mismo.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es JPEG XL en Chrome 155?
Es el soporte nativo de decodificación del formato de imagen .jxl que Chrome incorpora a partir de la versión 155, usando un decodificador reescrito en Rust llamado jxl-rs en lugar de la implementación histórica en C++.
¿Chrome 155 también permite crear archivos .jxl?
No. El anuncio de Google cubre solo la decodificación: Chrome puede mostrar imágenes .jxl que ya existen, pero no incluye un encoder nativo para generarlas desde el navegador.
¿El formato JPEG XL reemplaza a AVIF o WebP?
No los reemplaza, compite con ellos en casos de uso distintos. Google recomienda probar tanto AVIF como JPEG XL: AVIF suele rendir mejor en compresión general con pérdida, mientras JPEG XL se destaca en fidelidad alta, modo sin pérdida y transcodificación reversible de JPEG.
¿Por qué Google reescribió el decodificador en Rust en vez de usar libjxl directamente?
Porque los decodificadores de imágenes procesan datos binarios no confiables dentro del proceso que renderiza la página, y son uno de los blancos más explotados en navegadores. Rust elimina en la fuente errores de memoria que el sandbox solo mitiga después de que ocurren.
¿JPEG XL funciona igual en Firefox y Safari?
No todavía. El soporte fuera de Chrome es parcial o inexistente según el navegador, así que conviene servir JPEG XL con un formato de respaldo mediante el elemento picture hasta que la cobertura sea pareja.
Referencias
- Chrome for Developers: anuncio oficial del soporte de JPEG XL en Chrome 155 y detalles del decodificador jxl-rs.
- GitHub: libjxl: implementación de referencia en C++ del formato JPEG XL.
- JPEG.org: página oficial del comité JPEG sobre el estándar JPEG XL.
- Wikipedia: JPEG XL: historial del formato, incluida su remoción experimental de Chrome en 2022.
📱 ¿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.
Imagen destacada: Foto de Pankaj Patel en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios