JPEG, PNG, WebP o AVIF: qué formato y por qué

Dos preguntas, y el formato sale solo

Pregunta uno: ¿la imagen es fotográfica o de tintas planas? Fotográfica significa tono continuo — piel, cielo, follaje, ruido de sensor, ninguna zona donde el valor salte de un píxel al siguiente. De tintas planas significa lo contrario: capturas de pantalla, logotipos, gráficos, esquemas, línea, texto, todo lo que tenga grandes áreas uniformes y bordes duros entre ellas. No es una etiqueta estilística. Es una descripción estadística de los píxeles, y las dos familias de compresión se construyeron para estadísticas opuestas.

Pregunta dos: ¿la imagen necesita canal alfa o animación? El JPEG no tiene ninguno de los dos y nunca los tendrá. El PNG tiene alfa y solo anima mediante APNG, una extensión ausente de la especificación original. WebP y AVIF tienen ambos alfa y ambos animan. Si hace falta poner un logotipo sobre un fondo desconocido, el JPEG queda descartado antes de empezar la discusión sobre el tamaño — un logotipo JPEG llega con un rectángulo de fondo incrustado.

Qué le hacen realmente la DCT y DEFLATE a los píxeles

El JPEG trocea la imagen en bloques de 8 × 8 y reescribe cada bloque como una suma de ondas coseno, luego divide esos coeficientes entre una tabla de cuantización y redondea. El detalle fino vive en los coeficientes de alta frecuencia, justo los que la tabla divide con más fuerza: se redondean a cero y desaparecen. Una foto lo tolera porque sus altas frecuencias son en gran parte ruido. Un borde duro no: un escalón abrupto necesita muchos términos de alta frecuencia, y al borrarlos la reconstrucción se pasa y se queda corta a ambos lados del borde. Eso es el halo, y por eso el texto en un JPEG se ve borroso en los bordes incluso en alta calidad.

El efecto es medible, y estrictamente local a los bordes. En nuestra imagen de prueba plana tomamos una banda de 1040 píxeles de ancho por 70 de alto alrededor del titular. En el original, 56 119 píxeles de esa banda valen exactamente 255,255,255. Tras una sola pasada JPEG en calidad 75, 6 352 de ellos — el 11,3 % — ya no son blanco puro, con una desviación de hasta 14 niveles. En una banda blanca vacía de 86 400 píxeles lejos de cualquier borde, ni un píxel cambió. El JPEG no degrada la imagen de forma uniforme: la degrada exactamente donde vive el dibujo de tintas planas.

El PNG funciona al revés. Predice cada píxel a partir de sus vecinos, resta la predicción y entrega los residuos a DEFLATE — el mismo algoritmo que un archivo zip. Una tirada de píxeles idénticos se comprime a casi nada, y por eso una captura de pantalla encoge tan bien. Una foto no tiene tiradas: cada píxel difiere ligeramente de su vecino, los residuos son ruido y DEFLATE no encuentra agarre. Esa es toda la explicación de los 2 021 576 bytes que necesitó nuestra foto en PNG frente a 311 380 en JPEG.

Las mismas dos imágenes, cuatro codificadores, medidos

En la foto el orden es el que todo el mundo espera. PNG 2 021 576 bytes, JPEG en calidad 75 311 380, AVIF en la calidad 75 del codificador 174 774, WebP con pérdida en calidad 75 105 608. Pero lee ese último par con cuidado antes de concluir: la calidad 75 de un códec no es la calidad 75 de otro. Ese número es un índice en el cuantizador propio de ese codificador, nada más. Esas cifras solo dicen que estos dos codificadores, con ajustes nominalmente idénticos, cayeron en puntos distintos de la curva tamaño-calidad — no que WebP gane a AVIF. Cualquier comparación honesta entre dos códecs fija primero una métrica de calidad y luego compara bytes, y ese es un ejercicio mucho más largo que el de esta página.

La captura plana es donde ocurre la inversión interesante. PNG 88 693 bytes. JPEG con el mismo ajuste de calidad 75: 152 065 bytes — 1,71 veces el PNG, y encima tirando píxeles. WebP con pérdida: 40 060 bytes. WebP sin pérdida: 36 074 bytes, a la vez más pequeño que la versión con pérdida y exacto al píxel. No es una anomalía. El WebP con pérdida submuestrea siempre la crominancia a 4:2:0: el texto en color y los filetes finos de color pierden la mitad de la resolución de color horizontal y vertical, y el codificador gasta después bits en reconstruir bordes que él mismo acaba de difuminar. En dibujo de tintas planas, lo sin pérdida es con frecuencia a la vez más pequeño y mejor.

La puerta de un solo sentido — y el mito de volver a guardar

La pérdida es realmente de un solo sentido. Convertimos nuestro original PNG a JPEG calidad 75 y de vuelta a PNG: el PNG devuelto pesa 1 470 130 bytes, frente a 2 021 576 del original. Es más pequeño porque la pasada JPEG alisó detalle fuera de la imagen, y ningún codificador PNG puede reponerlo. A partir de ahí el archivo es sin pérdida, pero guarda sin pérdida una imagen dañada. PNG → JPEG → PNG nunca devuelve el original, y el tamaño menor es la prueba, no un premio.

La versión popular — que cada nuevo guardado agrava el daño — resulta falsa tal como se enuncia habitualmente, y lo medimos. Recodificar diez veces el mismo JPEG con el ajuste de calidad idéntico, sin recorte, sin redimensionado y sin retoque entre pasadas, movió el error absoluto medio de 1,7591 a 1,7670 niveles. Es una deriva de ocho milésimas de nivel en diez generaciones: la recuantización JPEG está cerca de un punto fijo mientras la rejilla de 8 × 8 siga alineada y la tabla de cuantización no cambie.

Cambia cualquier cosa entre guardados y el efecto acumulativo es inmediato. Repetimos la cadena con un pequeño recorte centrado antes de cada guardado, lo que desplaza la imagen respecto a la rejilla de 8 × 8. Tras seis ciclos, el error absoluto medio frente a una codificación de una sola pasada del mismo recorte había subido de 1,76 a 2,32 niveles — un 32 % más de error — mientras que codificar ese mismo recorte una sola vez desde el original intacto se mantenía plano en torno a 1,77 en cualquier ciclo comparado. La regla práctica no es, pues, «nunca vuelvas a guardar»: guarda el original sin pérdida, edita siempre a partir de él y exporta a JPEG o WebP como último paso, no como archivo de trabajo.

Alfa, profundidad de bits y los techos que nadie menciona

El PNG almacena hasta 16 bits por canal; el JPEG, tal como lo implementan los navegadores, 8. El WebP es de 8 bits en ambos modos, y su modo con pérdida es siempre 4:2:0. El AVIF llega a 10 y 12 bits y puede codificar en 4:4:4, y por eso es el único de los cuatro que maneja un degradado amplio y suave sin bandas, y el único con una respuesta real para HDR. Si tu imagen es un cielo de atardecer o un fondo de producto muy suave, esa profundidad vale más que cualquier tamaño de la tabla anterior.

El WebP lleva un techo duro que sorprende la primera vez: el contenedor codifica ancho y alto en 14 bits, así que ningún WebP puede pasar de 16 383 píxeles de lado. Irrelevante para una foto web, fatal para un mapa escaneado o un panorama largo cosido. El AVIF y el PNG no tienen un límite comparable en los tamaños que vas a producir. Conviene saberlo antes de montar una tubería que convierta todo a WebP por defecto.

Soporte y coste de codificación, y la regla que resulta

El soporte ya no es el factor decisivo que era hace cinco años. El WebP llegó a Chrome hace mucho, a Firefox 65 en enero de 2019 y a Safari 14 en septiembre de 2020. El AVIF llegó a Chrome 85 en agosto de 2020, a Firefox 93 en octubre de 2021, a Safari 16 en septiembre de 2022 y por fin a Edge 121 en enero de 2024 — Edge fue el último gran navegador en sumarse. Toda versión actual de todo navegador principal decodifica los dos. Queda una cola larga de sistemas antiguos que ya no pueden actualizar su navegador: justo para eso existe el elemento picture con varias fuentes y una reserva JPEG.

Lo que aprieta ahora es el coste de codificación. En la misma máquina y la misma foto de 1600 × 900, mejor de cinco ejecuciones: WebP 287 ms, AVIF 1 163 ms, JPEG 119 ms. El AVIF tardó cuatro veces más que el WebP, y casi diez veces más que el JPEG producido por la misma herramienta. Intervienen codificadores distintos — cwebp para WebP, el marco de imagen del sistema para AVIF y JPEG — así que toma la proporción exacta como indicativa, no universal. La dirección, en cambio, no está en duda: el AVIF es codificación intra AV1, explora un espacio mucho mayor y es lento por construcción. En un lote de cien mil imágenes eso es una partida presupuestaria real, y por eso muchos equipos se quedan en WebP.

La regla que se desprende de todo esto cabe en tres líneas. Foto sin transparencia: WebP o AVIF, con JPEG detrás para clientes antiguos. Captura de pantalla, logotipo, gráfico, cualquier cosa de tintas planas: WebP sin pérdida primero, PNG como reserva segura, y nunca JPEG. Todo lo que necesite alfa o animación: WebP o AVIF, o PNG si la paleta es pequeña y lo sin pérdida importa más que los bytes.

Preguntas frecuentes

¿El WebP siempre es más pequeño que el JPEG?

No. Suele serlo en fotos, y en la nuestra fue un 66 % más pequeño con un ajuste nominalmente igual — pero esos ajustes no son comparables entre códecs, y un JPEG ya muy comprimido puede crecer al pasar a WebP, porque el codificador tiene ahora que reproducir los bloques del JPEG como si fueran detalle. Mide siempre sobre tus propias imágenes en vez de fiarte de un porcentaje de titular.

¿Convertir un JPEG antiguo a WebP o AVIF restaura la calidad?

No puede. El detalle que el JPEG descartó no está en el archivo, así que nada aguas abajo puede recuperarlo. Convertir sigue mereciendo la pena para ahorrar ancho de banda, y un buen codificador no añadirá mucho daño nuevo, pero el techo lo fija el JPEG de partida. Si el raw o el PNG original aún existe, reexporta desde ahí — no cuesta nada más y el resultado es realmente mejor.

¿Debo seguir publicando JPEG?

Como reserva dentro de un elemento picture, sí — cuesta un archivo extra y cubre cualquier dispositivo jamás fabricado. Como formato principal para trabajo nuevo, ya no hay ningún caso fotográfico en que el JPEG gane en tamaño a igual calidad, ni ningún caso de tintas planas en que gane siquiera. También sigue siendo lo más seguro para entregar a alguien que lo abrirá con software desconocido, y por eso los adjuntos de correo y las imprentas siguen tirando de él.

¿PNG-8 o PNG-24 para un logotipo?

El PNG-8 guarda una paleta indexada de como mucho 256 colores y resulta mucho más pequeño cuando el dibujo tiene de verdad pocos colores — la mayoría de los logotipos planos. El PNG-24 guarda color completo y solo hace falta para degradados o sombras suaves. Comprueba el resultado en vez de la etiqueta: si la versión con paleta es visualmente idéntica, quédatela. Y compara ambas con el WebP sin pérdida, que superó al PNG en un 59 % en nuestra imagen plana de prueba.

¿Merece el AVIF el tiempo extra de codificación?

Depende por completo de cuántas veces se codifica cada archivo frente a cuántas se sirve. Una imagen principal codificada una vez y entregada un millón de veces: codifícala en AVIF y acepta el segundo extra. Contenido subido por usuarios y codificado al vuelo: cuatro veces la CPU por imagen es un coste operativo serio, y el WebP es la elección pragmática. El AVIF también se gana el sitio en degradados amplios y suaves, donde sus modos de 10 y 12 bits evitan bandas que los formatos de 8 bits no pueden.

¿Por qué el WebP sin pérdida ganó al WebP con pérdida en la captura?

Porque la codificación con pérdida es la herramienta equivocada para esos datos. La captura está hecha sobre todo de tiradas largas de píxeles idénticos, que el modo sin pérdida codifica casi gratis, mientras que el modo con pérdida primero submuestrea el color y luego gasta bits describiendo los bordes que difuminó. Medimos 36 074 bytes sin pérdida frente a 40 060 con pérdida — más pequeño y exacto al píxel. Si tu imagen es de tintas planas, prueba lo sin pérdida antes de tocar el control de calidad.