Mozilla ha anunciado hoy sus planes definitivos para llevar la decodificación de JPEG XL a la versión estable de Firefox. La compañía confirma que Firefox 157, previsto para finales de septiembre de 2026, activará este formato de imagen por defecto en todas las plataformas, dejando atrás años de soporte limitado a las compilaciones Nightly bajo una bandera experimental.
El anuncio llega a través de una entrada en el blog Mozilla Hacks y de un mensaje a la lista de correo de desarrollo del navegador Firefox. Os explicamos los detalles: ahora mismo, Firefox Nightly ya tiene JPEG XL habilitado por defecto para que el equipo de Mozilla depure el decodificador antes del salto a la rama estable.
De la bandera oculta en Nightly al soporte por defecto
Durante varios años, Mozilla mantuvo una postura que buena parte de la comunidad calificó de indecisa. La compañía reconocía el mérito técnico de JPEG XL, pero lo dejaba escondido detrás de una bandera de configuración, disponible solo en Nightly, sin ningún compromiso público de llevarlo a producción. En paralelo, dentro de la comunidad de Linux llegaron a circular paquetes no oficiales de Firefox con JPEG XL activado por defecto, al margen de la postura oficial del navegador.
Ese periodo de indefinición se cierra con el anuncio de hoy. Mozilla explica que el trabajo realizado durante los últimos ciclos de Nightly, en los que JPEG XL lleva activo por defecto para recoger datos de estabilidad y rendimiento, le da la confianza necesaria para dar el salto a la rama estable. Firefox 157 heredará esa configuración: el decodificador funcionará sin que el usuario tenga que tocar ninguna opción avanzada, tanto en Windows como en macOS y Linux. El propio soporte experimental viene de más atrás: las versiones 152 y posteriores ya permitían activarlo de forma opcional, oculto tras una bandera de configuración en los ajustes avanzados del navegador.
JPEG XL frente a AVIF: dos formatos para usos distintos
Mozilla no presenta JPEG XL como un sustituto de AVIF, sino como una alternativa complementaria. En su entrada de blog, la compañía resume que JPEG XL sobresale en imágenes sin pérdida, en la recompresión de archivos JPEG ya existentes sin perder calidad y, sobre todo, en el renderizado progresivo: esa capacidad de mostrar una vista previa reconocible de la imagen mientras el resto de los datos todavía está llegando. Esa diferencia resulta especialmente útil en conexiones móviles lentas, donde el usuario ve antes un boceto reconocible de la fotografía mientras el resto de los datos sigue llegando, en lugar de esperar ante un hueco en blanco hasta que la imagen termine de cargar.
AVIF, por su parte, sigue siendo la opción más eficiente para fotografías de calidad web con una mezcla de bordes definidos y superficies planas, y suele generar archivos más pequeños que JPEG XL en ese escenario concreto. Su punto débil, según Mozilla, es que su soporte de renderizado progresivo es solo básico. Por eso la compañía apunta que, en imágenes muy grandes, puede compensar aceptar un archivo algo más pesado con JPEG XL a cambio de una carga visual más fluida para quien la está viendo.
Google formaliza sus planes para JPEG XL en Chrome y Blink
El anuncio de Mozilla no llega aislado. El mismo día, Google formalizó su intención de enviar la decodificación de JPEG XL en Blink, el motor que sustenta Chrome y el resto de navegadores basados en Chromium, para todos los usuarios por defecto. Chrome ya incorpora un decodificador nativo del formato, apoyado en jxl-rs, el decodificador que desarrolla Google Research escrito en Rust y pensado para ofrecer rendimiento junto con seguridad de memoria.
El movimiento contrasta con la postura que mantuvo la propia Google en 2022, cuando retiró JPEG XL de Chromium después de años de soporte experimental. La retirada generó una notable presión por parte de la comunidad de desarrolladores, que empujó a la compañía a revisar su posición en los años siguientes hasta llegar al anuncio formalizado hoy. La existencia de jxl-rs refuerza ese cambio de rumbo, aunque la compañía todavía no ha detallado en qué versión de Chrome llegará la decodificación por defecto ni si coincidirá con el calendario previsto para Firefox 157.