El mejor formato de imagen de la década perdió la guerra sin llegar a pelearla. JPEG XL comprime mejor que AVIF, codifica más rápido y entiende los JPEG de siempre, pero Google lo expulsó de Chrome a finales de 2022 y la web lo dio por muerto. En febrero de 2026, Chrome 145 lo devolvió a la vida con un decodificador en Rust.
Este análisis reconstruye por qué perdió un formato superior, qué cambió para que Google rectificara tres años después y qué deberías servir hoy en tu web. La historia importa porque se repite cada vez que una gran plataforma decide qué tecnología vive y cuál no, como ya vimos con Office en Linux y Flatpak.
La promesa de JPEG XL
JPEG XL nació para jubilar al JPEG sin romper nada. Creado en colaboración entre Google Research y Cloudinary con guía del grupo de expertos fotográficos, el formato comprime entre un 30 y un 60 por ciento mejor que el JPEG clásico según la imagen, con codificación más rápida que AVIF y una carta ganadora que nadie más tenía. Recomprime los JPEG existentes a menor tamaño sin perder un solo bit, así que migrar un archivo histórico no cuesta calidad.
El fotógrafo guarda menos peso con la misma mirada. La web carga antes con idéntica fidelidad. Los archivos custodian décadas de fotos en menos disco sin tocar un solo píxel de los originales. Sobre el papel no tenía rival, porque mejoraba al abuelo en todo y empataba o ganaba al retador moderno en casi todo lo demás.
La cronología de Cloudinary de marzo de 2026 cuenta la saga con dramatismo poco habitual en un blog técnico. Google, paradójicamente, fue uno de los padres de la criatura y también su verdugo. Esa contradicción es el corazón de esta historia.
¿Por qué Google lo expulsó de Chrome en 2022?
A finales de 2022, Google retiró el soporte experimental de JPEG XL en Chromium con un argumento demoledor. No había suficiente interés del ecosistema para continuar. La frase, citada hasta hoy en cada debate, sonaba a sentencia técnica cuando en realidad describía una profecía autocumplida. Sin Chrome no hay ecosistema, y sin ecosistema no hay Chrome. El resto de navegadores miró hacia otro lado y los desarrolladores archivaron el formato.
Detrás del motivo oficial pesaba una apuesta rival. Google había invertido años en AVIF, construido sobre el códec de vídeo AV1 de la Alianza por los Medios Abiertos, donde la propia Google manda. AVIF ya volaba en YouTube y Netflix, tenía hardware de decodificación en camino y un relato industrial impecable. Sostener dos formatos nuevos a la vez dividía esfuerzos, y la empresa eligió al hijo de la casa frente al sobrino brillante.
La comunidad protestó con razón. Fotógrafos, archiveros y desarrolladores de herramientas libres señalaron que enterrar un formato superior por falta de ecosistema, cuando tú eres el ecosistema, roza el abuso de posición. La protesta no sirvió de nada en 2022. Sirvió para dejar constancia, que tres años después pesaría en la rectificación.
El regreso de JPEG XL
The Register contó la reconciliación el 14 de enero de 2026. Google reintegró el decodificador JPEG XL en el código de Chromium, revirtiendo la decisión de 2022. Un mes después, Chrome 145 llegaba al canal estable el 10 de febrero con soporte nativo, según detalla el seguimiento de Lilting de marzo de 2026.
La clave técnica del regreso tiene nombre y es Rust. El nuevo decodificador está escrito en un lenguaje con seguridad de memoria, lo que elimina de un plumazo la objeción de seguridad que pesaba sobre el código C anterior. Como explica ImageGuide en agosto de 2026, Chrome 145 reañadió la decodificación tres años después de quitarla gracias a ese decodificador memory-safe. La misma razón que devuelve Rust al corazón de Ubuntu devolvió JPEG XL al navegador.
El contexto también ayudó. Apple soporta JXL en Safari desde 2023, Firefox lo mantiene tras una bandera y el formato maduró en herramientas de autor. Cuando Chrome volvió, ya no volvía al desierto de 2022 sino a un ecosistema que había sobrevivido sin él. La profecía autocumplida se rompió por el extremo contrario. Alguien mantuvo la llama encendida.
JPEG XL frente a AVIF, ¿cuál sirve hoy?
La pregunta práctica no admite romanticismo. Para producción web en 2026, la recomendación de OpenReplay de julio de 2026 es nítida. Sirve AVIF, con un 93 por ciento de cobertura global en navegadores a mitad de 2026 y soporte maduro en CDN, CMS y herramientas de build. JPEG XL es técnicamente el formato más fuerte, con codificación más rápida y mejor respuesta, pero su cobertura todavía se está reconstruyendo tras el regreso a Chrome.
| Formato | Compresión | Codificación | Cobertura 2026 | Mejor uso |
|---|---|---|---|---|
| JPEG clásico | Referencia | Instantánea | Universal | Compatibilidad total |
| AVIF | Excelente | Lenta | 93 por ciento | Web en producción hoy |
| JPEG XL | Excelente y superior | Rápida | En reconstrucción | Archivo y futuro web |
| WebP | Buena | Media | Universal | Transición sin riesgos |
La tabla esconde una decisión por casos que conviene explicitar antes de tocar tu pipeline de imágenes, porque cada escenario pide un formato distinto y equivocarse cuesta ancho de banda o compatibilidad.
- Fotografía y archivo a largo plazo van en JPEG XL, por su recompresión sin pérdidas de JPEG y su velocidad de codificación.
- Web pública masiva va en AVIF con respaldo en WebP o JPEG, por cobertura y tooling.
- Experimentos y sitios de vanguardia pueden servir JXL con fallback, para ir calentando la tubería.
Si gestionas un archivo fotográfico, migrar los JPEG a JXL sin pérdidas ahorra entre un tercio y la mitad del espacio sin tocar un píxel. Si gestionas una tienda con un millón de visitas, AVIF con CDN es la respuesta sensata este año. Confundir ambos escenarios es como elegir cámara por los megapíxeles.
Audacity 4.0 renueva el software de audio libre con Qt6
El catálogo de trucos no termina en la compresión. JPEG XL maneja alto rango dinámico y gamuts amplios para fotografía seria, decodifica en progresivo para conexiones lentas y hasta admite animación para sustituir al GIF sin sus miserias. Nada de eso lo tiene AVIF en un solo paquete, y todo viaja en un contenedor pensado para durar décadas. Quien archiva piensa en estos detalles más que en el titular del ratio.
¿Cómo empiezo a usar JPEG XL hoy?
Probarlo cuesta diez minutos y no compromete nada. En Debian y Ubuntu existe el paquete de herramientas oficial de la biblioteca de referencia, que instala el codificador y el decodificador de línea de comandos. La guía de Konvrt de abril de 2026 recorre este mismo camino para desarrolladores que quieren servir JXL cuanto antes.
sudo apt install libjxl-tools
cjxl foto.jpg foto.jxl -q 90
djxl foto.jxl foto-recuperada.pngLa primera orden convierte con calidad visual 90 sobre 100, un punto donde el ojo no distingue el original. La segunda invierte el proceso para comprobar que todo sigue en su sitio. Si vienes de un archivo JPEG, la gracia está en la recompresión sin pérdidas, que recorta entre un tercio y la mitad del peso sin tocar un píxel. Para lotes grandes, un bucle del shell con find hace el trabajo de una tarde mientras tomas café.
En la web, la forma correcta de servirlo es el elemento picture con fallbacks encadenados, de modo que cada navegador elige el primer formato que entiende. El visitante con Chrome 145 recibe JXL, el de un navegador antiguo cae a AVIF o JPEG sin enterarse.
<picture>
<source srcset="foto.jxl" type="image/jxl">
<source srcset="foto.avif" type="image/avif">
<img src="foto.jpg" alt="Descripción de la foto">
</picture>Verifica el resultado abriendo la página en Chrome y en Safari, y comprueba en las herramientas de desarrollo qué archivo descarga cada uno. Mide después el peso total con la pestaña de red antes y después del cambio. Si el ahorro no compensa la complejidad de generar tres variantes por imagen, tu CDN ya hace bien su trabajo y puedes esperar sentado a que la cobertura termine de cuajar.
¿Qué lección deja para los formatos abiertos?
La primera lección es que la superioridad técnica no vota. JPEG XL ganaba en casi cada benchmark y perdió tres años por una decisión de producto de una sola empresa. Los formatos abiertos necesitan padrinos con navegadores, no solo comités con especificaciones. Sin un Chrome, un Safari o un Firefox empujando, el mejor códec es un paper bonito.
La segunda lección es que la seguridad vende lo que la compresión no pudo. El decodificador en Rust desbloqueó el regreso donde los porcentajes de compresión fracasaron. Escribir infraestructura crítica en lenguajes con seguridad de memoria se ha convertido en el argumento que abre puertas en navegadores y distribuciones. Quien mantenga un códec en C haría bien en tomar nota.
La tercera lección mira a las Big Tech de frente. Una plataforma puede enterrar un estándar abierto con una frase sobre el ecosistema y desenterrarlo tres años después con otra. La comunidad que mantuvo vivo JXL en herramientas libres, visores y flujos de archivo merece más crédito que el comunicado de rectificación. Sin esos guardianes no habría habido nada a lo que volver. Las alternativas libres para escapar de las Big Tech existen justo para estos casos.
El formato que volvió del olvido
JPEG XL no fue un fracaso técnico, fue un fracaso político con final de reconciliación. Perdió la batalla de 2022 contra los intereses de su propio creador y ganó la de 2026 con un decodificador seguro y un ecosistema que se negó a morir. Hoy convive con AVIF en un reparto sensato según el uso que le des a cada imagen.
Si editas fotos, prueba a convertir tu archivo a JXL y mira el espacio que recuperas. Si desarrollas webs, deja el conducto preparado con fallbacks mientras la cobertura termina de cuajar. Y la próxima vez que una plataforma entierre algo excelente por falta de interés del ecosistema, pregunta quién es el ecosistema. La respuesta suele tener logo y sede en Mountain View.