Las discusiones sobre formatos suelen empezar por el códec y avanzar hacia fuera. Es al revés. El formato correcto lo decide lo que hay en la imagen, y solo después lo que acepta el sistema que la va a recibir.
Fotografías: JPEG o WebP
Las imágenes de tono continuo —caras, paisajes, cualquier cosa con degradados y ruido— se comprimen bien con códecs con pérdida, porque el ojo tolera errores pequeños en las zonas cargadas. JPEG es la opción segura por defecto porque lo acepta todo el mundo. WebP con pérdida llega a la misma calidad percibida con bastantes menos bytes, así que gana siempre que el destino lo permita.
Una advertencia si vas a usar ToolZool para esto: nuestro compresor escribe WebP solo en su modo sin pérdida, que en una fotografía produce un archivo varias veces más grande que el JPEG equivalente. Para una fotografía con un límite de tamaño, elige aquí JPEG. El motivo de esa diferencia está en la página del propio compresor: no existe ningún codificador de WebP con pérdida que podamos incluir sin una licencia incompatible o una cadena de compilación de C.
Gráficos planos y texto: PNG
Los logotipos, los iconos, los diagramas y las capturas de interfaces están hechos de bordes duros y de grandes zonas de color idéntico. Los códecs con pérdida se llevan mal con los bordes duros: aparecen halos visibles alrededor del texto y, como el ruido que introducen es a su vez caro de codificar, el archivo acaba siendo a menudo más grande que un PNG sin pérdida de esa misma imagen.
La transparencia decide por ti
JPEG no tiene canal alfa. Convierte a JPEG un PNG con transparencia y las zonas transparentes se vuelven sólidas: normalmente negras, a veces blancas y casi nunca lo que querías. PNG y WebP admiten alfa los dos, así que si la imagen tiene transparencia la lista se reduce a esos dos.
Dónde encaja AVIF
AVIF gana a WebP en tamaño de archivo a igualdad de calidad, sobre todo con bitrates bajos, y todos los navegadores actuales pueden mostrarlo. El problema es codificar: es muchísimo más lento y mucho más pesado de ejecutar que JPEG o WebP, algo que importa cuando la codificación ocurre en un móvil y no en un servidor de compilación.
Hoy ToolZool ni lee ni escribe AVIF. Las dos direcciones necesitan un códec AV1, y todos los que se mantienen son bibliotecas en C que no compilan a WebAssembly, así que un archivo AVIF hay que convertirlo antes en otra parte. Lo mismo pasa con HEIC, que es lo que produce por defecto la mayoría de los iPhone.
La pregunta que está por encima de todo esto
¿Qué acepta el formulario? Un formato mejor que acaba rechazado no es mejor. Lee primero la lista de formatos admitidos y optimiza dentro de ella; y si un archivo que parece cumplir sigue sin pasar, por qué un formulario rechaza tu archivo repasa las cuatro comprobaciones que hace de verdad un formulario. Si necesitas cambiar de formato, el compresor de imágenes lee JPG, PNG y WebP y escribe JPEG, PNG o WebP sin pérdida, así que sirve también de conversor dentro de ese grupo.
