JPEG XL o JPEG
Hemos pasado 16 fotos de móviles y cámaras por los dos formatos. JPEG XL salió más pequeño en todas: alrededor de una quinta parte sin tocar un píxel, y entre un 20% y un 33% menos cuando los dos comprimen hasta la misma calidad visual. JPEG sigue ganando en dos: velocidad y, sobre todo, compatibilidad, que es lo que decide casi todas las elecciones reales.
por Robert Castillo · Publicado el
La respuesta corta
Para guardar fotos, JPEG XL gana en tamaño en todo lo que hemos medido; lo paga en velocidad. Coge un JPEG que ya tienes y lo encoge en torno a un 20% con la garantía de que el archivo original se puede reconstruir exacto, y cuando comprimes una foto desde cero necesita bastantes menos bytes que JPEG para la misma calidad visual.
Para mandar fotos a otra gente, JPEG sigue siendo lo seguro. Desde octubre de 2026 los tres navegadores principales (Chrome, Firefox y Safari) lo muestran por defecto, y Edge todavía no. Es un cambio de verdad, pero muchas aplicaciones, formularios y dispositivos antiguos todavía no se han puesto al día. JPEG se abre en todas partes; JPEG XL se abre cada mes en más sitios.
El resto de la página son las pruebas: dos ensayos, los números de cada foto y cómo los hicimos exactamente, con enlaces a cada foto, para que puedas repetirlos.
Prueba 1: reempaquetar JPEG sin perder nada
Esto es lo que la gente quiere decir con que JPEG XL es "un 20% más pequeño". Cuando a cjxl le das un JPEG, por defecto no descodifica la imagen para volver a comprimirla. Recodifica los propios datos del JPEG con una codificación de entropía mejor, así que los píxeles quedan exactamente como estaban, y guarda lo necesario para reconstruir el archivo original.
Lo probamos con 16 JPEG tal y como se subieron a Wikimedia Commons, todos de dominio público (CC0): siete de móvil (dos iPhone 13, dos iPhone 12, dos Google Pixel 7 y un Samsung Galaxy S21 Ultra) y nueve de cámara (Fujifilm, Canon, Olympus, Nikon y Sony), de entre 7,8 y 26,8 megapíxeles. Después devolvimos cada .jxl a JPEG con djxl y comparamos la suma SHA-256 con la del original.
| Foto | JPEG | JPEG XL | Ahorro |
|---|---|---|---|
| Fujifilm X-T3 · río a la hora azul | 11,46 MB | 8,47 MB | 26,1% |
| Fujifilm X-T3 · aves entre hojas | 14,29 MB | 10,75 MB | 24,8% |
| Canon EOS 6D · catedral y cielo azul | 7,28 MB | 5,88 MB | 19,3% |
| Canon EOS 6D · cisnes en vuelo | 1,53 MB | 1,09 MB | 28,9% |
| Olympus E-M10 II · amapola | 9,42 MB | 8,12 MB | 13,8% |
| Olympus E-M10 II · burbuja helada, macro | 7,25 MB | 5,61 MB | 22,7% |
| Nikon D7500 · paisaje rural | 8,42 MB | 6,06 MB | 28,1% |
| Nikon D7500 · locomotora de vapor | 6,35 MB | 5,07 MB | 20,2% |
| Sony A7R IV · barco en el mar | 2,50 MB | 1,92 MB | 23,1% |
| iPhone 13 · acuario | 7,42 MB | 6,19 MB | 16,5% |
| iPhone 13 · fachada de noche | 4,45 MB | 3,68 MB | 17,3% |
| iPhone 12 · manantial y árboles | 2,80 MB | 2,27 MB | 18,8% |
| iPhone 12 · coche rojo (mapa de ganancia HDR) | 5,97 MB | 4,89 MB | 18,0% |
| Pixel 7 · paisaje con bruma (mapa de ganancia + foto en movimiento) | 4,76 MB | 4,23 MB | 11,1% |
| Pixel 7 · estación de tren (mapa de ganancia) | 3,68 MB | 3,03 MB | 17,8% |
| Galaxy S21 Ultra · hojas | 3,96 MB | 3,32 MB | 16,1% |
| Las 16 | 101,53 MB | 80,56 MB | 20,7% |
Los 16 archivos volvieron idénticos bit a bit: misma suma de comprobación, mismo tamaño y mismos metadatos. Eso es lo que lo hace seguro para archivar. No tienes que fiarte de que el resultado "se vea igual": puedes demostrar que es el mismo archivo.
El ahorro fue de entre el 11,1% y el 28,9%, con una mediana del 19,0%. Los archivos de cámara encogieron más que los de móvil (un 23,0% frente a un 16,5% de media), pero hay que leerlo con cuidado: cinco de los nueve no salían directamente de la cámara. Cuatro los había grabado Lightroom, Camera Raw, Photoshop o el Digital Photo Professional de Canon, y uno estaba recortado, así que esto compara estos archivos concretos más que cámaras con móviles. Parte de la diferencia se ve en la prueba de jpegtran que viene más abajo: varios de esos archivos usaban tablas de codificación genéricas, así que hasta el optimizador de toda la vida les encontró hasta un 12% de margen, frente a alrededor de un 3% en los JPEG de móvil.
Subir el esfuerzo apenas sirve. Con esfuerzo 9 en lugar del 7 por defecto el ahorro pasó del 20,7% al 20,9%, a cambio de unas ocho veces más tiempo de procesador. El ajuste por defecto es el bueno.
La pega: mapas de ganancia HDR y fotos en movimiento
Tres de nuestras fotos de móvil llevan algo pegado detrás del final de la imagen principal. Las dos del Pixel 7 incluyen un mapa de ganancia Ultra HDR, una segunda imagen pequeña que le dice a una pantalla HDR cómo dar brillo a la foto, y una de ellas lleva además el vídeo corto de una foto en movimiento. La del iPhone 12, hecha con iOS 26, lleva el mapa de ganancia HDR propio de Apple.
cjxl conserva todo eso, por eso la ida y vuelta sigue siendo exacta, pero guarda esos bytes extra tal cual: solo sabe reempaquetar el JPEG principal. Por eso la foto del Pixel con vídeo dentro solo ahorró un 11,1%. Midiendo solo la imagen principal, esas mismas tres fotos encogieron entre un 18,3% y un 21,5%, en línea con las demás.
El optimizador clásico de JPEG hace algo peor. jpegtran parece ahorrar un 50,7% en esa foto del Pixel, pero solo porque tira sin avisar el mapa de ganancia y el vídeo y deja los metadatos que dicen que existen. Si pasas optimizadores "sin pérdida" por la fototeca del móvil, comprueba antes qué hacen con estos extras.
Frente a los optimizadores clásicos de JPEG
Optimizar un JPEG sin pérdida no es nuevo: jpegtran lleva décadas reescribiendo las tablas de Huffman. Para comparar lo comparable, aquí van las 13 fotos que no llevan datos extra al final, así que no se tira nada.
| Método | Ahorro | Qué obtienes |
|---|---|---|
| jpegtran -optimize | 5,2% | Sigue siendo un JPEG; mismos píxeles, pero no el archivo original |
| jpegtran -progressive | 9,5% | Sigue siendo un JPEG; mismos píxeles, pero no el archivo original |
| cjxl (por defecto, esfuerzo 7) | 21,5% | Un .jxl; el JPEG original se reconstruye byte a byte |
| cjxl -e 9 | 21,7% | Un .jxl; el JPEG original se reconstruye byte a byte |
JPEG XL ahorra más o menos el doble que el mejor truco que se queda en JPEG. El precio es que el resultado ya no es un JPEG, así que lo que tenga que abrirlo necesita soporte de JPEG XL, o un djxl rápido para volver al original.
Prueba 2: a la misma calidad visual, ¿cuántos bytes?
Reempaquetar solo sirve para los JPEG que ya tienes. La otra pregunta es qué pasa cuando guardas una foto desde cero, por ejemplo después de editarla. Comparar "calidad 80" en un codificador con "calidad 80" en otro no significa nada, porque las escalas no tienen relación. Así que igualamos la calidad con una métrica perceptual.
Redujimos cada foto a 2048 píxeles de lado largo, lo que borra casi todo el rastro de su compresión JPEG original, y la codificamos con muchos ajustes de calidad en cuatro codificadores: libjpeg-turbo con su submuestreo de color 4:2:0 por defecto, libjpeg-turbo con color completo 4:4:4, jpegli de Google y JPEG XL. Cada resultado se descodificó y se puntuó frente a la referencia con SSIMULACRA2, y para cada foto interpolamos cuánto tiene que pesar cada codificador para llegar a la misma puntuación.
En la propia escala de SSIMULACRA2, 70 es calidad alta, con defectos difíciles de ver sin el original al lado; 80 significa que no distingues las dos poniéndolas una junto a otra al 100%; 85, que no las distingues alternando entre ellas; y 90 es visualmente sin pérdida.
| Puntuación | JPEG turbo | JPEG jpegli | JPEG XL (frente a jpegli) |
|---|---|---|---|
| 70 · calidad alta | 339 KB | 292 KB | 239 KB (−22%) |
| 80 · iguales una al lado de otra | 529 KB | 469 KB | 382 KB (−20%) |
| 85 · iguales alternando | 792 KB | 664 KB | 535 KB (−23%) |
| 90 · visualmente sin pérdida | 1.373 KB* | 1.289 KB | 964 KB (−24%) |
Los tamaños son la mediana de las 16 fotos, llevada a una imagen de 2048 × 1536 (3,1 megapíxeles). "JPEG turbo" es libjpeg-turbo con su color 4:2:0 por defecto, más -optimize -progressive. El porcentaje bajo JPEG XL es su ahorro mediano frente a jpegli, el mejor de los dos codificadores JPEG, calculado foto a foto. *Solo 13 de las 16 fotos llegaron a 90 con libjpeg-turbo; más abajo explicamos por qué.
JPEG XL dio el archivo más pequeño en todas las fotos y en todos los niveles: 80 comparaciones de 80 frente a jpegli y 77 de 77 frente a libjpeg-turbo. Frente a libjpeg-turbo, la biblioteca JPEG que usan la mayoría de programas y sistemas operativos, el ahorro mediano fue de entre un 28% y un 33% según el nivel; con una puntuación de 80 fue del 16% al 63% según la foto. jpegli, de Google, recorta parte de esa distancia, pero en los niveles de la tabla JPEG XL siguió necesitando entre un 20% y un 24% menos de bytes. Es una cifra más modesta que algunas que leerás por ahí, y es la que dieron de verdad nuestras fotos.
Las mayores diferencias salieron en imágenes limpias y suaves: con una puntuación de 80, los cisnes contra el cielo azul y la amapola contra las nubes necesitaron en JPEG XL menos de la mitad de bytes que con libjpeg-turbo, y alrededor de un 40% menos que con jpegli. Las escenas densas y llenas de detalle, como el manantial con árboles o el coche rojo, aún salieron entre un 14% y un 16% más pequeñas que con jpegli. En un cielo liso JPEG no tiene dónde esconderse: sus bloques de 8×8 se notan antes que nada en forma de bandas y cuadros.
Además hay un techo. Con su submuestreo de color 4:2:0 por defecto, libjpeg-turbo no llegó a 90 en 3 de las 16 fotos ni siquiera con calidad 100, porque reducir a la mitad la resolución del color limita lo fiel que puede llegar a ser. Pasarlo a color completo 4:4:4 lo arregla, pero cuesta más bytes en los niveles habituales: necesitó más que la versión 4:2:0 hasta el 80 y menos a partir del 85.
Si quieres los ajustes en vez de las puntuaciones: llegar a 80 pidió una calidad mediana de 83 en libjpeg-turbo y en jpegli, y una distancia de 1,6 en cjxl. Llegar a 85 pidió calidad 91 y distancia 1,0, que es justo lo que cjxl usa por defecto cuando la entrada no es un JPEG. Lo visualmente sin pérdida (90) pidió calidad 97 en libjpeg-turbo y distancia 0,5 en cjxl.
Velocidad: donde JPEG sigue ganando con claridad
JPEG XL ahorra espacio trabajando más, y en un solo núcleo se nota. Para llegar a una puntuación de 80, libjpeg-turbo gastó una mediana de 0,04 segundos de procesador por megapíxel, jpegli 0,06 y cjxl con su esfuerzo por defecto 0,77: entre 13 y 20 veces más trabajo que JPEG. En la práctica sigue siendo menos de un segundo para una foto de 3 megapíxeles, pero se acumula cuando procesas decenas de miles de archivos.
Al descodificar pasa lo mismo, con menos diferencia. En la prueba de reempaquetado, djpeg convirtió los JPEG originales en píxeles en 0,019 segundos por megapíxel y djxl necesitó 0,049 para las mismas fotos reempaquetadas en JPEG XL, unas 2,5 veces más en un solo hilo. Para una foto de móvil de 12 megapíxeles es más o menos un cuarto de segundo frente a seis décimas. Reconstruir el archivo JPEG original a partir del .jxl costó 0,045 segundos por megapíxel.
El reempaquetado sin pérdida, en sí, es barato: 0,12 segundos de procesador por megapíxel con el esfuerzo por defecto, así que alrededor de 1,4 segundos para una foto de 12 megapíxeles. Con esfuerzo 9 costó cerca de 1 segundo por megapíxel a cambio de un 0,2% más. Herramientas como djxl y cjxl pueden además repartir el trabajo entre varios núcleos, lo que acorta la espera pero no el trabajo total.
Compatibilidad en octubre de 2026
Esta es la fila que decide casi todo en la vida real, y se ha movido más en las dos últimas semanas que en los tres años anteriores.
| Dónde | JPEG | JPEG XL |
|---|---|---|
| Safari (Mac, iPhone, iPad) | Sí | Desde Safari 17 (2023); sin carga progresiva ni animación |
| Chrome | Sí | Por defecto desde Chrome 155 (6 de octubre de 2026) |
| Firefox | Sí | Desde Firefox 158 (13 de octubre de 2026) |
| Edge | Sí | No en Edge 155: Microsoft lo retiró de las notas de esa versión el 9 de octubre de 2026 |
| Windows 11 (Fotos, Explorador) | Sí | Con la Extensión de imágenes JPEG XL, gratuita y de Microsoft, versión 24H2 o posterior |
| Windows 10 | Sí | Sin soporte oficial |
| Android (galería, sistema) | Sí | No está en la lista oficial de formatos de Android; Chrome lo muestra en las páginas web |
| Correo, mensajería, formularios | Universal | Depende: pruébalo antes de fiarte |
Las fuentes: el cambio de Chrome figura como activado por defecto desde la versión 155 en Chrome Platform Status, y Firefox lo anunció en sus notas de la versión 158. Si quieres saber qué hace tu navegador ahora mismo, nuestro test de JPEG XL en el navegador lo comprueba en un segundo. Y si un .jxl llega a un equipo que no lo abre, el visor o pasarlo otra vez a JPG lo resuelve sin instalar nada.
¿Cuál usar?
Archivar los JPEG que ya tienes
JPEG XL, reempaquetando sin pérdida. Más o menos un 20% menos de disco, y el archivo original siempre se puede reconstruir exacto.
Guardar fotos editadas
JPEG XL si controlas dónde se van a abrir. La misma calidad en bastantes menos bytes, o más calidad con el mismo tamaño.
Mandárselas a alguien
JPEG. Es el único formato que sabes seguro que la otra persona va a abrir, en cualquier aparato y en cualquier aplicación.
Imágenes de una web
JPEG XL ya es viable con un JPEG de respaldo dentro de un elemento <picture>. Sin respaldo, todavía no.
Fotos HDR del móvil
Reempaquétalas si quieres, pero el mapa de ganancia se guarda tal cual y el ahorro es menor. Nunca las pases por jpegtran.
Miles de imágenes, deprisa
JPEG codifica y descodifica varias veces más rápido. Si el tiempo de proceso importa más que el espacio, eso sigue contando.
Cómo lo hemos medido
Máquina: un servidor Ubuntu 24.04 compartido, con 6 núcleos virtuales AMD EPYC. Los tiempos son tiempo de procesador (usuario más sistema) de cada comando, en un solo hilo cuando la herramienta lo permite, lo que los hace mucho menos sensibles a la carga del servidor que el tiempo de reloj. Tómalos como proporciones, no como cifras absolutas.
Herramientas: libjxl 0.12.0 (cjxl, djxl, ssimulacra2), libjpeg-turbo 2.1.5 (cjpeg, djpeg, jpegtran), jpegli compilado desde su repositorio de GitHub en el commit 031a007 (junio de 2026) e ImageMagick 6.9.12 para reducir las fotos.
Comandos de la prueba 1: cjxl foto.jpg foto.jxl --num_threads=0, lo mismo con -e 9, después djxl foto.jxl vuelta.jpg y comparación de SHA-256. Para comparar, jpegtran -copy all -optimize y jpegtran -copy all -progressive.
Comandos de la prueba 2: referencias hechas con convert foto.jpg -auto-orient -resize 2048x2048 -strip. JPEG con cjpeg -quality Q -optimize -progressive (y -sample 1x1 para 4:4:4) en calidades de 20 a 100, jpegli con cjpegli -q Q en las mismas calidades y JPEG XL con cjxl -d D en distancias de 0,2 a 15. Los JPEG se descodificaron con djpeg, los JPEG XL con djxl, y todo se puntuó con ssimulacra2. Los tamaños en cada objetivo se interpolan entre los dos ajustes más cercanos, foto a foto.
Las 16 fotos (Wikimedia Commons, todas CC0), para que puedas repetir la prueba: río a la hora azul, aves entre hojas, catedral, cisnes, amapola, burbuja helada, paisaje rural, locomotora, barco, acuario, fachada de noche, manantial y árboles, coche rojo, paisaje con bruma, estación de tren, hojas.
.jpg){kind=link}
.jpg){kind=link}
,_enkei.jpg){kind=link}
.jpg){kind=link}
_de_nuit.jpg){kind=link}
.jpg){kind=link}
Límites: 16 fotos es una muestra pequeña, no un estudio, y con otro conjunto el resultado se movería. SSIMULACRA2 lo ha desarrollado la misma gente que hizo JPEG XL; se usa mucho y se corresponde bien con lo que valoran las personas, pero otra métrica o un panel de observadores podrían ordenar las cosas de otra forma. Nuestras referencias salen de JPEG, no de archivos RAW. Los scripts, los resultados de cada ajuste en CSV y el origen y la licencia de cada foto se guardan junto a las medidas, y los compartimos encantados.
Preguntas frecuentes
¿Pasar de JPG a JPEG XL pierde calidad?
cjxl por defecto con un JPEG y lo que hace también por defecto nuestro conversor de JPG a JPEG XL: los píxeles no se tocan y el JPEG original se reconstruye byte a byte. Lo comprobamos con SHA-256 en los 16 archivos de la prueba. Solo se pierde calidad si recodificas la imagen a propósito con un ajuste con pérdida.¿Cuánto encoge un JPEG al pasarlo a JPEG XL?
¿Puedo volver del JPEG XL al JPG original?
djxl foto.jxl foto.jpg te devuelve el archivo idéntico, metadatos incluidos.