JPEG XL en la línea de comandos: cjxl y djxl

La respuesta corta

Las herramientas oficiales de JPEG XL para la línea de comandos salen de libjxl, la implementación de referencia del formato. Con tres programas se hace casi todo: cjxl codifica, djxl descodifica y jxlinfo te dice qué hay dentro de un archivo. La versión actual es la 0.12.0, publicada el 1 de julio de 2026, y todos los comandos, salidas y cifras de esta página salen de ejecutarla nosotros.

Si te quedas con un solo comando, que sea este: cjxl foto.jpg foto.jxl. Cuando le das un JPEG, cjxl no vuelve a comprimir la imagen: reempaqueta los datos que el JPEG ya tiene de forma más eficiente. Con nuestra foto de prueba ahorró un 26,9%, y djxl reconstruyó el JPEG original con la misma suma de comprobación, metadatos incluidos.

Lo demás son detalles, pero algunos pillan por sorpresa. Un PNG se comprime con pérdida si no dices lo contrario, una opción de calidad sobre un JPEG da error en vez de aplicarse, y la versión que instala Ubuntu 24.04 tiene cuatro años. Todo eso está más abajo, con su solución.

Instalar cjxl, djxl y jxlinfo

Todos los sistemas importantes tienen paquete, pero la versión que te llevas cambia muchísimo de uno a otro. Estas son las que ofrecía cada fuente el 15 de octubre de 2026:

Windows. winget instala el zip oficial como aplicación portátil y añade su carpeta al PATH de tu usuario, así que cierra la terminal y abre otra antes de escribir cjxl --version. Si prefieres hacerlo a mano, descarga jxl-x64-windows-static.zip de la página de la versión 0.12.0 y descomprímelo: los programas están en x64-windows-static\bin. Añade esa carpeta al PATH o llama a cjxl.exe con su ruta completa. El zip que baja winget es exactamente ese, con la misma suma de comprobación.

macOS. En Homebrew el paquete se llama jpeg-xl, no libjxl. Instala cjxl, djxl, jxlinfo y jxltran, más las herramientas de desarrollo de libjxl (entre ellas ssimulacra2 y butteraugli_main), compilado todo a partir del código de la 0.12.0.

Comprueba qué tienes. cjxl --version responde con una línea como cjxl v0.12.0 4128790 [_AVX2_,SSE4,SSE2]; lo de los corchetes son las instrucciones del procesador que está aprovechando. No lo intentes con jxlinfo, que no tiene opción de versión (lo explicamos debajo de la tabla de errores).

Reempaquetar un JPEG sin perder ni un bit

Esta es la conversión que busca casi todo el mundo, y en la que JPEG XL no tiene rival: archivos más pequeños sin renunciar a nada, y reversible cuando quieras.

Ese último paso es el que importa. No es «visualmente idéntico»: es el mismo archivo, byte a byte, con el EXIF y el perfil de color dentro. En Linux o Mac puedes comprobarlo sin crear ningún archivo temporal: djxl foto.jxl - --output_format jpg | cmp - foto.jpg no dice nada si coinciden.

Con cada JPEG, cjxl añade un aviso, Implicit-default for JPEG is lossless-transcoding, que solo te cuenta lo que ha decidido. Si pones --lossless_jpeg=1 la decisión queda explícita y el aviso desaparece. En el lado de la descodificación, la 0.12.0 estrena --reconstruct_jpeg (-J): en vez de sacarte un JPEG nuevo cuando no puede reconstruir el original, djxl se para con Error: could not decode losslessly to JPEG.

La compatibilidad también funciona hacia atrás. El djxl 0.7.0 de Ubuntu reconstruyó nuestro archivo hecho con la 0.12.0 y devolvió el JPEG idéntico. El formato se publicó como norma en 2022 (ISO/IEC 18181); lo que sigue avanzando son las herramientas.

La trampa: opciones de calidad sobre un JPEG

Prueba cjxl foto.jpg foto.jxl -d 1 con la versión 0.12.0 y no se escribe nada: sale un error que empieza por Must not set non-zero distance (con -q, por Must not set quality below 100), y lo tienes completo en la tabla de errores. cjxl está protegiendo el reempaquetado sin pérdida: una distancia no pinta nada cuando no va a tocar los píxeles.

Si de verdad quieres un archivo con pérdida y más pequeño a partir de un JPEG, hay que decirlo: cjxl foto.jpg foto.jxl --lossless_jpeg=0 -d 1. Nuestra foto salió con 800.133 bytes, menos de un tercio que el reempaquetado. El precio es una segunda ronda de pérdida sobre una imagen que ya se comprimió una vez y, como verás en el apartado de metadatos, parte de los metadatos. Para un archivo que vas a guardar, el 27% sin pérdida sale más a cuenta.

La versión 0.7.0 se porta de otra manera, y aquí es donde muerde: con ella, -d 1 sobre un JPEG se ignora en silencio. Nuestro comando de prueba terminó sin error y escribió un reempaquetado sin pérdida. O sea, un script que «funcionaba» en Ubuntu 24.04 falla con la 0.12.0, y uno que contaba con -d para encoger los JPEG nunca los encogió. Si escribes --lossless_jpeg=0 o =1 de forma explícita, las dos versiones hacen lo mismo.

Sin pérdida desde PNG quiere decir -d 0

Con PNG, APNG, PPM y el resto de formatos de píxeles, lo que hace cjxl por defecto es -d 1: visualmente sin pérdida, pero con pérdida. Para fotos que solo vas a mirar está bien; para capturas de pantalla, escaneos, ilustraciones o cualquier cosa que estés archivando, donde quieres conservar cada píxel, no. Pon -d 0 (o -q 100).

Nuestra foto guardada como PNG pesaba 9.854.523 bytes. A -d 0 salió así con cada esfuerzo (mediana de tres pasadas hasta el 7, una sola del 8 al 10):

Con el esfuerzo por defecto queda un 34% por debajo del PNG, y al descodificarla de nuevo compare -metric AE de ImageMagick contó 0 píxeles distintos. Donde el esfuerzo rinde de forma más constante es aquí: el 9 deja el archivo un 4,6% más pequeño que el 7 a cambio de esperar seis veces y media más, y el 10 rasca otro 1,4% a cambio de cinco minutos y medio con una sola foto (324 y 337 segundos en dos pasadas distintas). Usa el 9 para un archivo que vas a crear una vez y guardar durante años.

El GIF es la excepción en sentido contrario: cjxl lo codifica sin pérdida por defecto, como verás en el apartado de animaciones.

Metadatos: qué se conserva y qué no

Nuestra foto de prueba lleva EXIF (con cámara y fecha), XMP, IPTC y un perfil ICC ProPhoto. Para comprobar el GPS y las palabras clave se los añadimos con exiftool a un segundo JPEG pequeño. Esto es lo que salió por cada camino:

El reempaquetado sin pérdida es el camino seguro: vuelve el JPEG entero, y con él hasta el último byte de metadatos. exiftool lee el EXIF y el XMP directamente del .jxl; el bloque IPTC y el perfil ICC original viajan dentro de los datos de reconstrucción y reaparecen al reconstruir el JPEG.

La sorpresa está en recodificar un JPEG con pérdida: cjxl 0.12.0 conservó el EXIF, posición GPS incluida, pero se dejó por el camino el XMP y el IPTC. Si tus palabras clave, valoraciones o ajustes de Lightroom van en el XMP, vuelve a meterlo a mano: exiftool -xmp -b foto.jpg > foto.xmp y luego añade -x xmp=foto.xmp al comando de cjxl. Comprobamos que así el campo de autor llega al .jxl.

Para quitar el GPS y el resto del EXIF antes de compartir una foto está -x strip=exif. Sobre un JPEG se niega con Cannot strip exif metadata, try setting --allow_jpeg_reconstruction=0., porque el original ya no se podría reconstruir byte a byte. Añade esa opción y funciona: la imagen se sigue reempaquetando sin pérdida, pero djxl pasa a decir Decoded to pixels. y escribe un JPEG nuevo en lugar del original. Y para sacar los metadatos de un .jxl basta con poner la extensión del tipo en la salida: djxl foto.jxl foto.exif o djxl foto.jxl foto.xmp.

Archivos progresivos (-p)

-p reordena el archivo para que una descarga a medias ya enseñe la imagen entera, con menos detalle. Cuesta un poco: nuestra foto con pérdida pasó de 799.774 a 852.155 bytes (+6,5%). Para ver qué se compra con eso, cortamos las dos versiones antes de su final, descodificamos lo que quedaba con djxl --allow_partial_files y lo puntuamos frente al original:

Sin -p la imagen también ocupa todo el encuadre pronto, pero casi toda se queda en un borrón provisional hasta que llegan casi todos los datos. Con -p, el 60% del archivo ya puntúa 65,6. Merece la pena para imágenes que se sirven en una web, y no aporta nada en un archivo de copias. También funciona al reempaquetar JPEG: nuestra foto creció un 1,9% y siguió volviendo idéntica byte a byte.

Convertir una carpeta entera en Windows (PowerShell)

Lo mismo para Windows. Cambia la ruta de la primera línea y pega el bloque entero en una ventana de PowerShell. Al pegarlo, en vez de guardarlo como archivo .ps1, te evitas la directiva de Windows que por defecto bloquea la ejecución de scripts:

Se comporta exactamente igual que la versión de bash, y lo probamos de la misma manera: dos veces sobre la carpeta de nombres raros, en Windows PowerShell 5.1 con Windows 11 y en PowerShell 7.6 en Linux. -LiteralPath es lo que impide que un nombre con corchetes se lea como comodín, y la comparación -in no distingue mayúsculas, así que los .JPG también entran. Los mensajes van sin tildes a propósito: si algún día lo guardas como .ps1 con el Bloc de notas, PowerShell 5.1 no te los desfigura. Para comprobar un resultado a mano: djxl foto.jxl prueba.jpg y después (Get-FileHash foto.jpg).Hash -eq (Get-FileHash prueba.jpg).Hash tiene que decir True.

Hay un límite común a los dos scripts: si foto.jpg y foto.png están juntas, las dos quieren llamarse foto.jxl, así que la segunda se salta. Cambia antes el nombre a una de ellas.

Preguntas frecuentes