¿Es WebP realmente más pequeño que JPG para imágenes de sitios web?

Comparamos JPG, WebP y AVIF en la misma foto de 538.6 KB en el mismo control deslizante, y JPG ganó. Aquí está el porqué de esto y lo que muestra la comparación justa.

August 9, 2026

Cada guía te dice que WebP es aproximadamente un 30% más pequeño que JPG con calidad equivalente. El propio estudio de Google es de donde proviene esa cifra. Hicimos la comparación en nuestro propio compresor con una foto de 3840x2160, texture.jpg de 538.6 KB, y en la misma posición del control deslizante el JPEG ganó: 286.1 KB frente a 290.3 KB para WebP. AVIF, el formato que se supone debe superar a ambos, llegó a 312.7 KB.

Nada se rompió. Los tres formatos leen ese control deslizante de manera diferente, y uno de ellos lo hace deliberadamente. Una vez que sabes cuál, el resultado se invierte de la manera que esperarías, y obtienes un hábito que vale la pena llevar a cualquier herramienta que ya uses.

¿Por qué WebP resultó ser más grande que JPG en el mismo control deslizante?

Nuestro compresor tiene una peculiaridad que comparten muchas herramientas y casi ninguna menciona. Cuando el formato de salida es JPEG y la entrada ya era un JPEG, lee las tablas de cuantización del archivo fuente, estima la calidad con la que se guardó ese archivo, y luego multiplica tu control deslizante contra esa estimación. Una fuente que puntúa 60 con el control deslizante en 80 se codifica en 48. WebP y AVIF no reciben tal tratamiento, así que 80 significa 80 y el codificador hace lo que se le dice. Esa ejecución en la parte superior fue JPEG a un efectivo 48 contra WebP a un literal 80. Un archivo comprimido más fuerte es más pequeño.

La reescalación se gana su lugar. Re-codificar un JPEG ya con pérdida a 80 cuando fue escrito a 60 añade bytes sin añadir ningún detalle de vuelta, así que tratamos el control deslizante como una fracción de lo que queda en el archivo. El problema más profundo pertenece a JPEG mismo: la especificación almacena tablas de cuantización en bruto y nunca almacena un número de calidad, así que 75 en Photoshop, 75 en MozJPEG y 75 en algún script PHP son tres archivos diferentes. Igualar el número en dos controles deslizantes y llamarlo una prueba justa no funciona.

¿Cómo se ven los tamaños cuando los comparas correctamente?

A 63, WebP escribe 200.6 KB de esa fuente de 538.6 KB. AVIF en la misma configuración llega a 186.9 KB, y 63 es lo que nuestro modo inteligente elige para AVIF de todos modos, así que no es un número que elegimos para halagar el formato. Igualar primero los tamaños de salida, luego abre ambos archivos a tamaño completo y decide cuál puedes aceptar. Esa es la comparación que vale la pena tener.

¿Debería usar AVIF entonces?

En bytes, AVIF gana. En paciencia, pierde. Codificar ese cuadro de 3840x2160 a AVIF tomó aproximadamente 10 a 11 segundos en el navegador, mientras que JPEG y WebP regresaron instantáneamente. Todo esto es WebAssembly ejecutándose en tu propia máquina, así que es tu laptop haciendo codificación intra AV1, y el costo escala con el recuento de píxeles. Hay una segunda trampa que vale la pena conocer: si el codificador WASM falla, volvemos al codificador de lienzo del navegador, y el lienzo puede escribir JPEG, PNG y WebP, pero no tiene un camino para AVIF. Para un gran lote, Google recomienda la herramienta nativa avifenc sobre las compilaciones de WebAssembly, y lo que diez codificaciones AVIF en una pestaña te costó también se mide.

¿Qué pierdo cuando convierto un JPG en un WebP?

Tres cosas concretas. Los metadatos van primero: comprimir o convertir decodifica la imagen a píxeles en bruto y la re-codifica, así que EXIF, coordenadas GPS, el perfil ICC y la miniatura incrustada se pierden en la salida. La orientación sobrevive, porque el navegador la aplica durante la decodificación. Si necesitas la fecha de captura, conserva el archivo original. Y un JPG con pérdida re-codificado como WebP con pérdida es una segunda generación de pérdida acumulada sobre la primera, así que hazlo una vez desde la mejor fuente que tengas.

El croma es la segunda pérdida. WebP con pérdida está limitado a submuestreo 4:2:0, sin opción 4:4:4 en ninguna parte del formato, así que una captura de pantalla de código con resaltado de sintaxis o un logo sobre rojo saturado puede verse peor en WebP que en un JPEG del mismo peso. Las fotos no se preocupan. El renderizado es el tercero: un JPEG progresivo pinta un cuadro completo de forma aproximada al principio y se agudiza a medida que llegan los bytes, y WebP no tiene modo progresivo, así que uno grande no muestra nada hasta que llega suficiente. En una imagen principal sobre una conexión débil, eso cambia la rapidez con la que se siente la página incluso cuando el archivo es más pequeño.

¿Gana WebP si la imagen tiene transparencia?

JPEG no puede hacer transparencia. No hay canal alfa en ningún modo JPEG, así que para un logo o un recorte, el verdadero concurso es PNG contra WebP, y el caso para cada uno de esos dos formatos se mide en estos mismos archivos. Nuestros números de PNG establecen la barra que tienes que superar: alpha.png a 900x606 y 942.4 KB bajó a 383.9 KB a través de oxipng sin pérdida en nivel 3, y a 98.3 KB una vez que imagequant lo redujo a una paleta, que es un 90% menos con la transparencia intacta. WebP almacena su alfa sin pérdida incluso dentro de un archivo con pérdida, así que los bordes del recorte permanecen limpios de cualquier manera. Si estás haciendo el recorte en primer lugar, nuestro eliminador de fondo siempre escribe PNG con alfa, y ese PNG puede ir directamente al compresor después.

¿Cuál debería poner realmente en el sitio?

Envía WebP para fotografías. Cada navegador actual lo decodifica, incluido Safari, y los ahorros son reales una vez que dejas de comparar números de control deslizante. Mantén JPG donde el archivo tiene que abrirse en software antiguo, o donde una imagen principal grande se beneficia más del renderizado progresivo que de 30 KB. La guía de formatos de imagen de MDN es la referencia a consultar antes de comprometer toda una biblioteca a un formato.

Verifica los píxeles primero. Una foto de 3840px es cuatro veces más ancha de lo que una columna de contenido de 960px mostrará, y ningún códec te devuelve lo que un redimensionado entrega gratis, así que el redimensionador con sus preajustes de 25/50/75 es un clic y generalmente supera el argumento del formato por completo. La escalera de calidad importa más que el formato también. Esa misma texture.jpg pasó a 212.4 KB a 60 y 131 KB a 30, y el modo inteligente se estableció en 286.1 KB, un 47% menos, sin preguntarte nada.

¿Cómo ejecuto esta prueba en mi propia imagen?

Abre el compresor, coloca tu foto y cambia a manual. Elige JPG, anota el tamaño. Cambia el menú desplegable de formato a WebP en ese mismo control deslizante y anota ese. Luego baja el control deslizante de WebP hasta que los dos archivos estén dentro de unos pocos KB el uno del otro, y míralos lado a lado a tamaño completo, porque esa es la única comparación que te dice algo. Los lotes están limitados a 10 archivos y 50 MB. Si prefieres omitir el control deslizante por completo, JPG a WebP codifica a una calidad fija de 80 sin reescalado, WebP a JPG va de regreso en la otra dirección con la transparencia en blanco, y la guía en PDF cubre la única conversión que hace que los archivos sean más grandes.