Firefox 157 llevará JPEG XL con un decodificador escrito en Rust
4 min de lectura

Mozilla publicó el 24 de agosto de 2026 su intención de llevar JPEG XL a Firefox, y Phoronix informa de que el formato quedará activado por defecto en todas las plataformas en Firefox 157, prevista para finales de septiembre. La condición que puso Mozilla es la parte interesante: en lugar de adoptar el decodificador de referencia en C++ que ya existía, encargó a Google Research uno nuevo en Rust, y ese decodificador -jxl-rs- es el que llevará Firefox.
Por qué había que reescribir primero el decodificador
Mozilla describe el encargo sin rodeos en su anuncio: pidió «jxl-rs, un decodificador de JPEG XL en Rust seguro, eficiente, compacto y compatible». Según Phoronix, la implementación en Rust se prefirió a la vía de C++ por motivos de rendimiento y de seguridad, y Bugzilla anota que Firefox usa jxl-rs en lugar de la implementación de referencia libjxl, en parte por su mejor integración con la propia arquitectura de Firefox.
Un decodificador de imágenes es más o menos el lugar menos indulgente de un navegador para ejecutar código no seguro: analiza entradas hostiles de cualquier sitio que visite el usuario, antes de cualquier decisión de aislamiento en la que la página pueda influir. Exigir un decodificador con seguridad de memoria antes de llevar un formato es un precio defendible para quienes impulsan ese formato, y llevó tiempo: Bugzilla remonta el trabajo a 2020, y la biblioteca que se lleva ahora es la versión 0.6.0.
En qué es bueno JPEG XL y dónde sigue ganando AVIF
Mozilla es llamativamente precisa al no tratar esto como una guerra de formatos. Su anuncio dice que JPEG XL destaca en imágenes sin pérdida, en renderizado progresivo y al recomprimir JPEG existentes sin perder calidad, mientras que AVIF es más fuerte en imágenes fotográficas y en contenidos que mezclan bordes nítidos con superficies planas.
El renderizado progresivo es la diferencia práctica. Mozilla dice que su implementación en Firefox lo prioriza, con una imagen mostrable en cuanto se han cargado unos kilobytes, y el compromiso queda dicho sin adornos en una línea que cita Phoronix: «AVIF solo tiene soporte básico de renderizado progresivo. Así que, para imágenes muy grandes, puede merecer la pena asumir el coste en tamaño de archivo de JPEG XL». Es algo raro en un anuncio de lanzamiento: el proveedor nombra el caso en que su nuevo formato produce un archivo más grande.
Cómo está el soporte ahora mismo
| Navegador | Estado |
|---|---|
| Firefox 157 (finales de septiembre de 2026) | Activado por defecto, todas las plataformas (Phoronix) |
| Firefox 152+ / Nightly | Experimental, detrás de la preferencia image.jxl.enabled (Phoronix, Bugzilla) |
| Chrome | Soporte retirado en M110 en marzo de 2023 (Bugzilla); Google ha formalizado ahora su intención de activarlo por defecto en Blink, anunciada a la vez que Mozilla (Phoronix) |
| Safari | Compatible en versiones recientes (Bugzilla) |
Bugzilla enumera lo que cubre la implementación de Firefox: decodificación progresiva, animación, gestión de perfiles de color mediante la integración CMS, HDR y CMYK. También enumera lo que no está terminado: la optimización de HDR, la integración de la decodificación multihilo y el propio cambio de la preferencia por defecto siguen registrados como trabajo abierto.
Qué significa esto para los desarrolladores
No rehagas tu pipeline de imágenes este mes. El estado honesto es este: Firefox ha anunciado una intención, Bugzilla sigue mostrando la preferencia desactivada fuera de Nightly, y el cambio del valor por defecto consta como trabajo abierto; el hito que hay que vigilar es que Firefox 157 salga de verdad a finales de septiembre, no este anuncio.
Lo que sí merece la pena ahora es medir. La afirmación distintiva de JPEG XL es la recompresión sin pérdida de JPEG existentes, así que coge un directorio real de tus JPEG de producción, recomprime una muestra y anota el ahorro en bytes y el comportamiento al decodificar. Ese número decide si el trabajo de pipeline vale la pena para tu sitio, y es específico de tus imágenes: una comparativa de formatos hecha con el archivo fotográfico de otra persona no te lo dirá.
Para todo lo que lleve imágenes muy grandes -mapas, escaneos, zoom de producto,
imagen médica o de archivo- la propia recomendación de Mozilla apunta a JPEG
XL, incluso a costa del tamaño, porque una imagen que se muestra de forma útil
tras unos kilobytes gana a un archivo más pequeño que aparece tarde. Si eso
describe tu producto, este es el anuncio sobre el que actuar. Si tus imágenes
son fotografías normales, AVIF sigue siendo el formato que Mozilla considera
más fuerte, y la acción correcta es mantener honestos los respaldos del
elemento picture y esperar.
La señal de fondo trata de cómo se adoptan hoy los formatos. Que un códec fuera bueno no bastó: Mozilla convirtió la seguridad de memoria en condición para llevarlo, y quienes impulsan el formato pagaron una reescritura en Rust para cumplirla. Cualquiera que espere meter un nuevo formato multimedia en los navegadores debería leer eso como la nueva línea de partida, y la aportación de Mozilla de pruebas de integración a los web-platform-tests dentro de Interop 2026 como la otra mitad de la misma exigencia.
Sources
- Intent to Ship: JPEG XL - Mozilla Hacks
- Mozilla Presents Their Plan For Shipping JPEG-XL In Firefox 157 - Phoronix
- Bug 1539075 - (JPEG-XL) Implement support for JPEG XL - Mozilla Bugzilla