Convertir AVIF a JXL

Haz esta conversión cuando algo exija JPEG XL por su nombre: una herramienta que no lee otra cosa, una cadena de trabajo montada alrededor del formato, una política de archivo que cita la norma ISO, o una prueba que vas a medir de verdad. Esos son motivos reales y esta página los sirve como es debido.

Si el motivo es que JPEG XL suena más moderno, quédate con el AVIF. Los dos comprimen lo bastante parecido como para que ninguno te sorprenda, la conversión cuesta una generación con pérdida, y el AVIF lo lee hoy cualquier navegador actual mientras que el otro sigue teniendo un soporte parcial. Que una página sobre una conversión te disuada de hacerla es un desenlace legítimo, y aquí es el desenlace de la mayoría.

AVIF lo publicó en 2019 la Alianza para Medios Abiertos, construido sobre el códec de vídeo AV1. JPEG XL llegó en 2022 desde el propio comité JPEG como norma ISO/IEC 18181-1, técnicamente ambicioso y en varios aspectos el diseño más elegante de los dos.

La adopción no siguió a los méritos. El soporte de AVIF es general en las versiones actuales de los navegadores; el de JPEG XL sigue siendo parcial, y por eso el registro lo clasifica como formato de nicho y por eso la demanda de uno es una fracción de la del otro. Esa brecha es el dato que más pesa a la hora de decidir si esta conversión te conviene, y no tiene nada que ver con qué códec es mejor.

El AVIF se descodifica a píxeles en bruto y esos píxeles se vuelven a codificar con el codificador de JPEG XL. No cruza nada en su forma comprimida, así que lo que descartó el primer codificador sigue descartado y el segundo toma después sus propias decisiones encima de eso.

Con la calidad por defecto de 82 la segunda pasada rara vez se ve en una fotografía, y tampoco es gratis. La textura fina, el grano y el leve enladrillado que un AVIF con pérdida deja alrededor de los bordes duros son justo lo que peor lleva un segundo codificador, porque gasta bits describiendo los errores del primero como si formaran parte del motivo. Si vas a quedarte solo con uno de los dos archivos, ese es un argumento directo para quedarte con el que se ha codificado una vez.

El número de calidad por defecto es 82 y es el mismo para los cuatro códecs con pérdida de este sitio; no hay ajustes distintos por formato escondidos en ninguna parte. Subirlo hacia 95 vuelve conservadora la segunda codificación, que es lo que quieres si el archivo va a editarse o a recodificarse otra vez después.

Hay algo que conviene decir aunque incomode: JPEG XL define un modo sin pérdida y este conversor no lo pide nunca. Siempre se codifica con pérdida, con el número de calidad que elijas. Si lo que buscabas era un JXL sin pérdida como copia maestra, esta página no te lo va a dar, y la respuesta correcta es un programa de escritorio que sí exponga ese modo.

Por debajo de 70 esta pareja concreta se estropea antes de lo que el número sugiere. El origen ya venía comprimido, así que los artefactos del primer codificador y los del segundo caen sobre los mismos bordes y se acumulan en lugar de repartirse, cosa que no pasa cuando se parte de una fotografía sin comprimir.

Si el objetivo es un tamaño agresivo, la palanca buena es otra: reducir el número de píxeles. Menos resolución con una calidad decente se ve mejor que la misma resolución con una calidad pobre, y además es el único cambio cuyo efecto se puede predecir antes de ejecutarlo.

El argumento práctico más fuerte a favor de JPEG XL es que puede tomar un JPEG existente y reempaquetarlo más pequeño sin tocar los datos de imagen y de forma completamente reversible. Es algo genuinamente raro entre formatos de imagen y explica que los grandes archivos fotográficos se lo tomen en serio.

Funciona porque lo que se hace es reordenar datos JPEG en lugar de recodificarlos, y un AVIF contiene datos AV1: una representación completamente distinta de la imagen, sin nada en común con un JPEG más allá de que ambos están comprimidos. No hay nada que reempaquetar, así que esta pareja no recibe ese beneficio. Si además de los AVIF conservas los JPEG originales en alguna parte, esos son los archivos interesantes para JPEG XL.

Sobre el papel, JPEG XL llega más lejos que AVIF en varias direcciones que importan a fotógrafos y a archiveros: admite más bits por canal, está pensado para gamas de color amplias y se diseñó con el almacenamiento a largo plazo de colecciones fotográficas como objetivo explícito y no como efecto colateral de un códec de vídeo.

Poco de eso te llega por esta conversión. Lo que entra en el codificador ya ha pasado por la tubería de imagen del navegador a ocho bits por canal, así que el margen de profundidad es teórico aquí y lo sería desde cualquier origen entregado por la web, que nunca tuvo más de ocho bits que dar. El sitio para ejercitarlo es una conversión desde un raw o desde un original de dieciséis bits en un programa de escritorio.

GIMP e ImageMagick leen JPEG XL, y los dos leen también AVIF, lo cual resume bien la situación en el escritorio: los programas que soportan uno suelen soportar el otro, así que la conversión rara vez resuelve un problema de «esto no se abre».

Más allá de ahí el terreno se adelgaza deprisa. Las vistas previas del sistema, los editores antiguos, los formularios de subida, los mensajeros y las imprentas en línea no manejan ninguno de los dos con frecuencia, y donde manejan uno suele ser AVIF, porque hay un motor de navegador incrustado dentro de muchísimo software que no es un navegador. Si lo que quieres es un archivo que otra persona abra sin tener que hablarlo, los dos son la respuesta equivocada y la página que buscas produce un JPG, un PNG o un PDF.

Un elemento de imagen con una fuente en JXL y una alternativa en AVIF o JPEG es la manera correcta de servir el formato, y funciona. Lo que no hace es ahorrarte nada, porque la alternativa tiene que existir y hay que generarla igualmente.

Esa es la aritmética incómoda de esta dirección para quien la hace por rendimiento. Empezabas con un formato que llega a todo el mundo a un tamaño cercano al mejor disponible y terminas con dos archivos, una negociación y una caché que tiene que guardar los dos. El ahorro en los visitantes que reciban el JXL tiene que pagar todo eso, y con un soporte parcial no suele pagarlo.

Los dos formatos pueden llevar EXIF, XMP y un perfil de color, y ninguno de esos bloques sobrevive a este camino. Toda conversión de imagen de este sitio descodifica a píxeles y escribe un archivo nuevo a partir de ellos, así que la fecha de captura, el modelo de cámara, las coordenadas y el perfil se quedan fuera; no se eliminan por decisión, es que nada los transporta.

Para un archivo que vas a entregar a alguien eso es una mejora de privacidad y un paso menos que recordar, porque el lugar donde se hizo una fotografía es lo que más se olvida quitar. Para quien recodifica una colección entera es una pérdida seria: la hora de captura es lo que ordena una fototeca, y una carpeta de imágenes que dicen todas haberse creado hoy no vale para casi nada. La conclusión honesta es que un conversor de navegador no es la herramienta para migrar una biblioteca.

Suelta una carpeta y los archivos se convierten uno tras otro en tu propio procesador, hasta cien de una vez, y vuelven juntos en un ZIP sin que se suba nada y sin ningún cupo diario que gastar. El límite es de 100 MB por archivo, muy por encima de cualquier imagen de entrega.

Y guarda los AVIF. Son la generación anterior, son los que seguirán mostrándose en un navegador dentro de cinco años, y repetir esta conversión más adelante no cuesta nada si resulta que las copias en JXL eran las que no hacían falta. Borrar el origen para ganar espacio entre dos formatos de tamaño tan parecido es el único error de esta página que no tiene vuelta atrás.