JPEG XL o PNG
Los dos son sin pérdida, así que recuperas exactamente los mismos píxeles. Lo comprobamos en las 20 imágenes de la prueba y luego medimos lo que cuesta. En fotos e ilustraciones gana JPEG XL con claridad. En capturas de pantalla, un PNG bien optimizado le ganó salvo que dejáramos a JPEG XL trabajar mucho más.
por Robert Castillo · Publicado el
La respuesta corta
Para fotos y para nuestras ilustraciones, JPEG XL es claramente más pequeño. Con sus ajustes por defecto redujo nuestras fotos en un tercio y nuestras ilustraciones en un 41% (un 43% las tres con transparencia de verdad) frente a PNG ya optimizados con el nivel máximo de oxipng (-o max, sin su modo Zopfli, más lento), y todos los píxeles volvieron idénticos.
Con las capturas de pantalla no es tan sencillo. Con el esfuerzo por defecto, JPEG XL fue más grande que un PNG bien optimizado en tres de nuestras cinco capturas. Solo se escapó con claridad con el esfuerzo 10, su ajuste más lento, donde en total las redujo un 53% (entre un 12% y un 75% según la captura). Y PNG se descodifica unas diez veces más rápido y se abre absolutamente en todas partes, lo que lo sigue haciendo la opción sensata para todo lo que vayas a compartir.
Qué probamos
Veinte imágenes de cuatro tipos. Ocho fotos de móviles y cámaras, todas de dominio público (CC0) de Wikimedia Commons, reducidas a 2048 píxeles de lado largo. Cinco capturas de pantalla de nuestra propia web a densidad normal, 2× (portátil) y 3× (móvil), más la salida de un terminal y una página de código mostradas en el navegador. Tres gráficos generados por nosotros con matplotlib. Y cuatro ilustraciones de Wikimedia Commons, CC0, renderizadas desde SVG; tres tienen fondo transparente y bordes suaves, y la cuarta, un mapa, es opaca casi entera.
Cada una se guardó como el PNG que escribió el programa que la creó (ImageMagick, Chrome, matplotlib o cairosvg), que es el PNG "sin optimizar" que tiene casi todo el mundo; pasada por oxipng 10.2.1 en su nivel por defecto y en el máximo; y como JPEG XL sin pérdida (cjxl -d 0) con esfuerzos 1, 2, 3, 7 (el de por defecto) y 9, más el esfuerzo 10 en todo menos en las fotos, donde tarda minutos por imagen.
Resultados por tipo de imagen
La referencia es el mejor PNG que pudimos sacar, con oxipng -o max. Totales por grupo; el porcentaje es frente a esa referencia.
| Imágenes | Mejor PNG | JPEG XL por defecto | JPEG XL más lento* |
|---|---|---|---|
| 8 fotos | 32,14 MB | 21,55 MB (−33%) | 21,36 MB (−34%) |
| 4 ilustraciones · 3 con transparencia | 1,05 MB | 0,62 MB (−41%) | 0,40 MB (−62%) |
| 3 gráficos | 0,37 MB | 0,27 MB (−26%) | 0,20 MB (−45%) |
| 5 capturas | 0,74 MB | 0,92 MB (+25%) | 0,34 MB (−53%) |
*Esfuerzo 9 en las fotos y 10 en todo lo demás. JPEG XL con el esfuerzo por defecto ganó al mejor PNG en todas las fotos (entre un 23% y un 40%), en todos los gráficos y en todas las ilustraciones. En las capturas perdió en tres de cinco, hasta un 54% en la página de código, que es justo el tipo de imagen en el que la gente da por hecho que JPEG XL arrasa.
Hay dos cosas que lo matizan. La primera, que la mayoría de capturas no pasan nunca por un optimizador: frente a los PNG tal y como los guardó Chrome, JPEG XL por defecto fue un 17% más pequeño en total. La segunda, que el esfuerzo 10 le da la vuelta por completo: la captura del terminal se quedó en menos de la mitad del mejor PNG y la página de código en una cuarta parte. El precio es el tiempo, que es la tabla siguiente.
Lo que te da cada nivel de esfuerzo
Tamaño frente al mejor PNG y tiempo de procesador por megapíxel en un solo núcleo. Una captura de móvil suele tener de 2,5 a 4 megapíxeles; una de nuestras fotos reducidas, unos 3.
| Ajuste | Fotos | Todo lo demás |
|---|---|---|
| oxipng, nivel por defecto | +0,4% · 1,4 s | +2,9% · 0,7 s |
| oxipng -o max | 0% · 11,6 s | 0% · 9,7 s |
| JPEG XL esfuerzo 1 | −13% · 0,07 s | +67% · 0,04 s |
| JPEG XL esfuerzo 3 | −29% · 0,38 s | +46% · 0,37 s |
| JPEG XL esfuerzo 7 (por defecto) | −33% · 1,8 s | −16% · 0,76 s |
| JPEG XL esfuerzo 9 | −34% · 10,9 s | −25% · 3,0 s |
| JPEG XL esfuerzo 10 | no se probó | −56% · 13,9 s |
En fotos, la sorpresa es el esfuerzo 1: un 13% más pequeño que el mejor PNG gastando unas 160 veces menos tiempo de procesador que oxipng -o max. El esfuerzo 3 se acerca mucho al resultado por defecto en una quinta parte del tiempo. Por encima del 7 apenas queda nada que ganar en fotos: el esfuerzo 9 ahorró otro 0,6% con seis veces más trabajo, y en una foto probamos también el esfuerzo 10, que ahorró un 3% más que el 9 tardando unas cuatro veces más todavía (unos dos minutos de procesador para 3,1 megapíxeles).
En capturas, gráficos y dibujos de colores planos pasa lo contrario: los esfuerzos bajos son peores que PNG y los altos, muchísimo mejores. Si archivas capturas en JPEG XL, usa el esfuerzo 9 o 10 y ten paciencia. Fíjate también en que el nivel por defecto de oxipng es casi tan bueno como el máximo, en una décima parte del tiempo.
¿Es de verdad sin pérdida? ¿Y la transparencia?
Sí, en todo lo que probamos. Descodificamos cada archivo JPEG XL (112, sumando todos los niveles de esfuerzo) y lo comparamos píxel a píxel con el PNG original, en rojo, verde, azul y alfa, con ImageMagick. El número de píxeles distintos fue cero en todos los casos. La misma comprobación con los archivos de oxipng también dio cero.
Eso incluye las tres ilustraciones con transparencia de verdad: los bordes suaves y semitransparentes del astronauta, el elefante y el robot volvieron exactos, y como grupo fueron donde JPEG XL ganó más (un 43% con el esfuerzo por defecto). Nuestros tres gráficos llevan un canal alfa totalmente opaco, que es lo que escribe matplotlib; los dos formatos lo conservaron sin problema, así que no hace falta quitarlo antes de convertir.
Todo esto es cjxl en la línea de comandos. Nuestro conversor de PNG a JPEG XL funciona de otra manera: es con pérdida salvo que marques «Sin pérdida», usa un esfuerzo rápido y lee la imagen a través del canvas del navegador, que trabaja en 8 bits y puede redondear los píxeles semitransparentes. Para una copia exacta de una imagen de 16 bits o con transparencia, usa cjxl -d 0.
Al descodificar, PNG es unas diez veces más rápido
Este es el coste que no viene en la etiqueta. En un solo núcleo, djxl necesitó 0,33 segundos por megapíxel para descodificar nuestras fotos sin pérdida y unos 0,19 para el resto de imágenes. Abrir esas mismas imágenes en PNG con Pillow, que usa la biblioteca zlib de siempre, costó entre 0,014 y 0,035 segundos por megapíxel.
Para una imagen en pantalla es la diferencia entre una fracción de segundo y un instante. Para una carpeta de miles de archivos sacando miniaturas, o para una página web llena de gráficos grandes sin pérdida, se nota. Los descodificadores pueden usar varios núcleos, y los navegadores y visores lo hacen, lo que acorta la espera, pero el trabajo sigue siendo unas diez veces mayor.
Si tu PNG es una foto, pregúntate si necesita ser sin pérdida
Muchas fotos acaban en PNG sin mejor motivo que el ajuste por defecto de una herramienta de capturas o de un editor. Guardar una foto sin pérdida sale caro en cualquier formato: nuestras ocho fotos ocuparon de media 2,7 MB cada una en JPEG XL sin pérdida.
En nuestra prueba de JPEG XL frente a JPEG, esas mismas fotos codificadas en JPEG XL con pérdida a calidad visualmente sin pérdida (una puntuación SSIMULACRA2 de 90, donde no ves diferencia ni alternando entre las dos) salieron una mediana de 3,3 veces más pequeñas que sin pérdida, y con una puntuación de 85, que sigue siendo excelente, unas 5,5 veces más pequeñas. Si el PNG es un original que vas a volver a editar, mantenlo sin pérdida. Si es una foto que solo quieres guardar, JPEG XL con pérdida entre -d 0.5 y -d 1 es, con mucho, el ahorro mayor.
Compatibilidad en octubre de 2026
Aquí la ventaja de PNG es total, y es la que más pesa cuando el archivo sale de tus manos.
| Dónde | PNG | JPEG XL |
|---|---|---|
| Chrome, Firefox, Safari | Sí | Sí: Safari 17+, Chrome 155+ y Firefox 158+ |
| Edge | Sí | No en Edge 155 |
| Windows 11 | Sí | Con la Extensión de imágenes JPEG XL, gratuita y de Microsoft (24H2 o posterior) |
| Android | Sí | No está en la lista oficial de formatos |
| Editores, ofimática, correo, chat | En todas partes | Irregular: compruébalo en cada uno |
Además PNG sigue moviéndose: su tercera edición, Recomendación del W3C desde el 24 de junio de 2025, añade oficialmente color HDR (con el bloque cICP) y PNG animado. Así que "PNG no hace HDR" ya no es cierto sobre el papel, aunque el soporte en los programas no ha hecho más que empezar. Si quieres saber qué hace tu navegador con un .jxl, nuestro test del navegador te lo dice en un segundo.
Cuándo PNG sigue siendo lo correcto, y cuándo no
Compartir o subir → PNG
Lo abre cualquier aplicación, editor, chat o formulario web. Eso solo ya decide casi todos los casos.
Capturas rápidas → PNG
Con los ajustes por defecto, un PNG optimizado ganó a JPEG XL en 3 de nuestras 5 capturas, y PNG se descodifica unas diez veces más rápido.
Miles de archivos que abrir → PNG
JPEG XL sin pérdida se descodificó unas diez veces más lento en nuestra prueba. Las miniaturas, vistas previas y procesos por lotes lo notan.
Archivo de fotos sin pérdida → JPEG XL
Un tercio menos que el mejor PNG con el ajuste por defecto, y todos los píxeles comprobados idénticos.
Ilustraciones y dibujos con transparencia → JPEG XL
Un 41% menos con el esfuerzo por defecto y un 62% con el 10, y cjxl conserva la transparencia exacta.
Capturas que archivas → JPEG XL, esfuerzo 10
Lento, pero en total las redujo un 53% frente al mejor PNG (entre un 12% y un 75% según la captura), más cuanto más texto tienen.
Cómo lo hemos medido
Máquina y tiempos: un servidor Ubuntu 24.04 compartido, con 6 núcleos virtuales AMD EPYC. Cada comando se ejecutó en un solo hilo (cjxl --num_threads=0, oxipng -t 1), uno detrás de otro, con un límite de 2,5 GB de memoria y la prioridad más baja, para que las webs del servidor fueran primero. Los tiempos son tiempo de procesador (usuario más sistema), al que apenas afecta la carga de la máquina; léelos como proporciones, no como lo que va a tardar tu ordenador.
Herramientas: libjxl 0.12.0 (cjxl, djxl), oxipng 10.2.1, ImageMagick 6.9.12 para reducir las fotos y para comparar píxeles (compare -metric AE en los cuatro canales), Pillow 12.3 para medir la descodificación de PNG, Chrome 146 para las capturas, matplotlib 3.10.8 para los gráficos y cairosvg 2.9.0 para las ilustraciones.
Comandos: oxipng -t 1 -o 2 y oxipng -t 1 -o max; cjxl entrada.png salida.jxl -d 0 -e E --num_threads=0 con E = 1, 2, 3, 7, 9 y 10; djxl salida.jxl comprobar.png para la comprobación de píxeles y djxl salida.jxl salida.pam --num_threads=0 para el tiempo de descodificación.
Límites: es una muestra pequeña, no un estudio. Teníamos previstas 16 fotos y pasamos 8 (cuatro de móvil y cuatro de cámara), porque la prueba hubo que frenarla y ejecutarla comando a comando en un servidor que también aloja webs; el esfuerzo 10 no se pasó por las fotos. No probamos imágenes diminutas como iconos, donde pesa más la cabecera del archivo, ni el optimizador más lento de PNG, zopfli. Las fotos salen de JPEG y están reducidas, así que son más limpias que un revelado de RAW; un archivo de fotos sin pérdida real puede comprimir de otra manera. Los scripts, los resultados por imagen en CSV y el origen y la licencia de cada imagen se guardan junto a las medidas.