JPEG XL aterriza en Firefox 157: qué cambia en tu pipeline de imágenes

Firefox activará la decodificación de JPEG XL por defecto en la versión 157, a finales de septiembre de 2026, y Chrome y Edge formalizaron su intención de activarla para todos los usuarios; Safari la soporta desde 2023. Mozilla lo anunció en su intent to ship del 24 de agosto con una conclusión clara: el formato estará soportado en los tres motores antes de que termine el año. Para equipos que producen sitios con imágenes, esto deja de ser una discusión de entusiastas: JPEG XL se convierte en una capa real de tu estrategia de entrega de imágenes, y la pregunta ya no es "¿soportan JXL?" sino "¿qué ganó y qué perdí si lo adopto?".

La historia corta de un formato que se fue y volvió

JPEG XL (ISO/IEC 18181) nació como el sucesor moderno de JPEG: compresión lossy y lossless, recompresión lossless de archivos JPEG existentes, decodificación progresiva, HDR de 32 bits y animación. En 2021, Firefox añadió soporte experimental detrás de un flag, pero el decoder de referencia eran unas 100,000 líneas de C++ multihilo, y Mozilla se negó a asumir esa superficie de ataque. Entonces hizo una apuesta pública: el equipo de JPEG XL en Google Research debía construir un decoder en Rust, seguro y rápido, y Firefox lo enviaría.

Ese decoder es jxl-rs, y cambió la historia del formato dos veces. Primero en 2022, cuando Chrome retiró JPEG XL por completo argumentando falta de interés —una decisión que la comunidad protestó durante años. Después en noviembre de 2025, cuando Chromium revirtió formalmente su posición y aceptó el decoder en Rust de Google Research: Chrome 145 (febrero de 2026) volvió a incluir JPEG XL, aunque detrás de un flag. Y ahora Firefox cierra el círculo: según el intent to ship publicado por Jake Archibald en Mozilla Hacks, Firefox 157 activa la decodificación por defecto en todas las plataformas, con jxl-rs como núcleo —la versión 0.6.0 ya es multihilo, y en las pruebas internas de Mozilla quedó a la par o por delante del decoder C++ de Safari en imágenes grandes—. La misma publicación confirma que Chrome también tiene intención de enviarlo.

El estado real del soporte (septiembre de 2026)

El detalle que más nos importa como agencia: la convergencia ocurre este trimestre, no en 2027. Los ciclos de lanzamiento quincenales de Chrome y Firefox hacen que la ventana "soportado en todas partes" se cierre más rápido de lo que la mayoría de equipos proyecta. Cuando Chrome pase el flag a default, un <picture> con JXL como primera opción llegará a más del 85% de los usuarios sin ningún fallback adicional.

Qué gana cada formato (y por qué no es una guerra)

La lectura honesta, coincidente entre la nota de Mozilla y los análisis independientes como el resumen de Web Standards: AVIF sigue ganando en fotografía lossy de bitrate bajo y medio; JPEG XL gana en todo lo demás.

Tres implicaciones prácticas que no aparecen en las tablas:

1. La recompresión lossless es una oportunidad inmediata. Cualquier archivo JPEG existente puede convertirse a JXL y reducirse ~20% con píxeles idénticos al original, reversible en cualquier momento. Para catálogos de e-commerce, fotogalerías y archivos de medios, es una reducción de bandwidth sin negociación de calidad. No requiere esperar a que Chrome active nada: se sirve como mejora progresiva.
2. La decodificación progresiva cambia la percepción de velocidad. AVIF y WebP renderizan cuando terminan de descargar; JXL muestra una versión de baja resolución mientras baja el resto. En conexiones lentas —el caso de gran parte de Latinoamérica— la diferencia percibida es mayor que la diferencia en bytes.
3. La codificación rápida de JXL baja el costo de pipeline. Generar variantes JXL es órdenes de magnitud más barato en tiempo de build que AVIF, lo que vuelve viable pre-generar el formato sin inflar los tiempos de compilación del sitio.

Lo que estamos haciendo en Mintec (y lo que recomendamos)

Nuestra línea base de producción es AVIF-first: en el sitio editorial de 2,500+ páginas que construimos en Astro, cada imagen se sirve en 5 variantes (AVIF, WebP y JPEG en dos tamaños) y el pipeline bajó de 5 MB originales a ~40 KB servidos, con un recorte del 73% en tiempo de build al delegar las galerías a transformaciones on-the-fly del CDN. Esa arquitectura —misma que documentamos también en nuestra guía AVIF vs WebP en Astro— se adapta a JXL sin rediseño, y este es el plan que estamos validando con clientes:

1. Pre-generar JXL solo de los activos que importan. Héroes, imágenes de producto y galerías visibles: no hace falta convertir el catálogo completo de una vez. La velocidad de encode lo vuelve barato.
2. Servir con <picture> ordenando type por prioridad — image/jxl primero, image/avif, image/webp, image/jpeg —y negociación por Accept header cuando el CDN lo permite. El navegador decide; nadie se queda sin imagen.
3. Aplicar recompresión lossless a los archivos JPEG heredados como primera fase: ganancia inmediata de ~20% sin cambiar una sola URL ni arriesgar calidad. Es el caso de negocio más fácil de aprobar.
4. Medir con métricas de campo, no con bytes. La hipótesis que estamos validando es que la decodificación progresiva mejora la percepción de LCP en conexiones lentas aunque el peso sea similar. Hasta que Chrome active el flag global, JXL se prueba con el tráfico Safari + Chrome con flag. Y si el encode server-side se convierte en cuello de botella, el procesamiento en el cliente con APIs nativas —como el que ya usamos para generar thumbnails de video con Web Codecs— es una ruta que no requiere infraestructura adicional.

Una advertencia que aprendimos en carne propia: los pipelines de imágenes también son superficie de ataque. El argumento de seguridad que mató a JXL en 2022 (C++ inseguro) se resolvió con Rust, pero cada formato nuevo que agregas a tu CDN es código que procesa bytes no confiables —el boletín de seguridad de Next.js de agosto de 2026 mostró una RCE por una imagen AVIF maliciosa en libheif. Versiona los decoders, audita los componentes de procesamiento y no dejes que un script de transformación no auditado maneje subidas de usuarios.

Conclusión: el trimestre de las imágenes

La secuencia es clara: Firefox 157 activa JXL por defecto en septiembre, Chrome formalizó su intención y Safari ya lo envía. Antes de que termine 2026, JPEG XL será el tercer formato moderno universal —y el único con recompresión lossless de JPEG, progresivo y HDR. No es momento de migrar todo a JXL por defecto; es momento de preparar la capa JXL en tu pipeline como mejora progresiva, empezando por la recompresión de tu archivo JPEG existente. Los equipos que tengan la variante lista cuando Chrome gire el flag ganarán ~20% de bandwidth en sus catálogos sin tocar calidad, y los que no, empezarán una migración con el sitio en producción.