# 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.*
Por Carlos Sánchez, con ayuda de IA
Publicado el 13 de octubre de 2026, 10:31 · Revisado el 13 de octubre de 2026, 13:16
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](https://developer.chrome.com/blog/jpeg-xl-in-chrome). 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](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types) (en inglés) y, para JPEG XL, los de su [web oficial](https://jpegxl.info/).
| 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](https://sanchezdonate.net/articulo/la-extension-webp/); 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:
*Mantiene prácticamente la misma calidad pero pesando mucho menos*
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 ``](https://sanchezdonate.net/articulo/etiqueta-picture/) con un `` 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 `` de respaldo, y [la documentación de imágenes de Google](https://developers.google.com/search/docs/appearance/google-images?hl=es) 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 |
## Referencias
1. caniuse.com (2026, 13 de octubre). *JPEG XL image format*. (soporte por navegador, consultado el 13 de octubre)
2. Chrome for Developers (2026, 6 de octubre). *Shipping JPEG XL in Chrome*. (fuente principal)
3. chromiumdash.appspot.com (2026, 13 de octubre). *Chromium Dash: calendario de versiones*. (Chrome 155 estable el 6 de octubre de 2026)
4. GitHub (2026, 13 de octubre). *Interop 2026 proposal: JPEG XL*. (la propuesta de Interop que cita Google)
5. Sánchez, C. (2022, 4 de marzo). *Etiqueta Picture enfocada al SEO*. sanchezdonate.net.
6. whattrainisitnow.com (2026, 13 de octubre). *Firefox 158 release schedule*. (calendario de Mozilla para la versión 158)
Contenido original bajo licencia CC BY 4.0, traducido y ampliado.