Chrome 155 ya abre JPEG XL: entre un 30 y un 50 % menos peso que JPEG
Chrome vuelve a aceptar JPEG XL, lo había retirado en 2023 por «falta de interés» pero ha cambiado de opinión. Promete entre un 30 y un 50 % mejor compresión que JPEG sin pérdida apreciable de calidad. Con Safari y, desde hoy, Firefox, el formato pasa a servirse en los tres grandes navegadores.
Carlos Sánchez con ayuda de IA
El anuncio lo hace el equipo de Chrome en su blog para desarrolladores: Chrome incorpora el soporte de decodificación de JPEG XL a partir de Chrome 155. Según el calendario de Chromium, esa versión llegó al canal estable el 6 de octubre, el mismo día de la entrada.
Google describe JPEG XL como un formato «de nueva generación» que ofrece «entre un 30 y un 50 % mejor compresión que JPEG, compresión sin pérdida, soporte de HDR integrado, transcodificación sin pérdida de JPEG y más».
Se recomienda no sustituir a AVIF sino hacer una combinación de ambos formatos de nueva generación para obtener los mejores resultados.
Calidad y peso: qué ofrece cada formato
Sobre el papel, las diferencias están en cómo comprime cada formato y en lo que es capaz de guardar. Los datos son los de la guía de formatos de imagen de MDN (en inglés) y, para JPEG XL, los de su web oficial.
| Formato | Compresión | Transparencia | Animación | Bits por canal | Carga progresiva |
|---|---|---|---|---|---|
| BMP | Admite varias, pero se suele guardar sin comprimir | Sí | No | 8 y 16 | No |
| PNG | Sin pérdida | Sí | Sí, como APNG | Hasta 16 | Entrelazado |
| JPEG | Con pérdida | No | No | 8 | Sí, en JPEG progresivo |
| WebP | Con o sin pérdida | Sí | Sí | 8 | No |
| AVIF | Con o sin pérdida | Sí | Sí | 8, 10 y 12 | No |
| JPEG XL | Con o sin pérdida, y recompresión sin pérdida de un JPEG (un 20 % menos de media) | Sí | Sí | Hasta 32 | Sí |
En la práctica, JPEG XL junta lo que antes había que repartir entre formatos: sin pérdida como PNG, con pérdida como JPEG o WebP, HDR y gama de color amplia como AVIF, y carga progresiva como el JPEG progresivo. Su web oficial asegura que es «visualmente sin pérdida con menos de la mitad de bits por píxel que JPEG».
La misma imagen en cinco formatos
Un ejemplo con la misma ilustración de 400 × 475 píxeles. Las cuatro primeras versiones son las del artículo sobre WebP de Carlos Sánchez; la de JPEG XL la ha exportado él a partir de la misma imagen.
| BMP | PNG | JPG | WebP | JPEG XL |
|---|---|---|---|---|
 |  |  |  |  |
| 742 KB | 227 KB | 53,8 KB | 44,5 KB | 27,9 KB |
Si la imagen en JPEG XL no se ve, tu navegador todavía no abre el formato: hace falta Chrome o Edge 155, Firefox 158 o Safari 17.
BMP y PNG guardan la imagen sin pérdida, y por eso pesan tanto; JPG y WebP la comprimen con pérdida. El JXL pesa un 37 % menos que el WebP y un 48 % menos que el JPG. Parte de esa diferencia son metadatos: el PNG, el JPG y el WebP llevan cada uno unos 13 KB de EXIF, XMP y perfil de color, y el JXL no lleva ninguno. Sin ellos, el JXL sigue siendo el más ligero: un 12 % menos que el WebP y un 31 % menos que el JPG, que además mide 400 × 449 y tiene algo menos de imagen que los demás.
Así se ve desde Chrome Canary con la versión 157:
Puedes poner en los comentarios si quieres que se añada Avif al experimento
Cómo implementarlo
La recomendación sería insertarlo dentro de un elemento <picture> con un <source type="image/jxl"> delante de la alternativa en AVIF, WebP o JPEG, o con negociación por la cabecera Accept en el servidor o el CDN. La Búsqueda de Google indexa la imagen del atributo src del <img> de respaldo, y la documentación de imágenes de Google solo admite BMP, GIF, JPEG, PNG, WebP, SVG y AVIF en ese atributo, así que el respaldo tiene que seguir siendo uno de esos formatos.
Donde más se nota es en el peso: menos bytes por imagen mejoran el LCP cuando la imagen grande es el elemento principal, y la transcodificación sin pérdida permite convertir un catálogo JPEG existente a JXL sin recomprimir y volver atrás si hace falta. La prueba razonable es tomar las diez imágenes más pesadas de la web, codificarlas en AVIF y en JXL con la misma calidad visual y comparar tamaños, como pide Google.
Un decodificador en Rust para no repetir la historia
Chrome ya tuvo JPEG XL detrás de una bandera experimental y lo retiró en 2023 alegando falta de interés del ecosistema. La vuelta se apoya en dos cosas. La primera es técnica: los decodificadores de imagen «son una de las superficies de ataque más críticas y atacadas de cualquier navegador moderno», porque procesan binarios de la red dentro del proceso de renderizado, y los escritos en C++ han dado fallos de memoria. Por eso Chrome integra jxl-rs, una implementación del decodificador «escrita íntegramente en Rust», con las instrucciones SIMD aisladas en «un número pequeño de lugares muy revisados». Google dice haberla verificado con fuzzing y revisión de código con IA sin encontrar «ningún fallo de seguridad de memoria en todo el historial de la implementación».
La segunda es la demanda: la decisión «se basó en el feedback y las peticiones constantes de los desarrolladores web, visibles sobre todo en el proceso de Interop, donde fue una propuesta popular en 2026 y varios años antes». Chrome ha participado en la investigación de JPEG XL de Interop 2026 para que haya cobertura de pruebas de todas las funciones del formato en los navegadores.
Dónde funciona hoy
| Navegador | Soporte de JPEG XL |
|---|---|
| Chrome | Desde la 155 (estable el 6 de octubre de 2026) |
| Safari | Desde la 17 (2023), imágenes fijas; sin animación ni decodificación progresiva, según caniuse |
| Firefox | Desde la 158, cuya salida está prevista para el 13 de octubre de 2026, según caniuse y el calendario de Mozilla |
| Edge | Desde la 155, según MDN |
