PNG vs JPG vs WebP: ¿qué formato gana realmente en 2026?

Estamos en 2026 y PNG (1996), JPG (1992) y WebP (2010) siguen todos en uso activo en producción en toda la web. No es pereza — cada uno ocupa un punto significativamente diferente en el triángulo de compensación entre tamaño de archivo, calidad y características, y reemplazarlos a todos con un solo formato haría perder información que realmente quieres conservar.

Esta es la historia más larga detrás de nuestra comparación más corta de PNG vs JPG, con WebP añadido y la pregunta sobre AVIF abordada.

El triángulo de compensaciones

*Existe APNG (PNG animado); la compatibilidad es amplia pero el formato rara vez es la elección correcta en 2026 — WebP y AVIF hacen mejor la animación.

Dónde gana cada uno

JPG gana cuando

• El recurso es una fotografía y necesitas compatibilidad universal (impresoras, clientes de correo electrónico antiguos, lectores de vista previa integrados).
• El recurso pasa por muchos ciclos de guardado — aunque cada guardado pierde calidad, la edición en JPG es el flujo de trabajo más compatible en los editores de imágenes.
• Algún consumidor heredado de tu imagen no admitirá nada más — sistemas integrados, software antiguo de tiendas de impresión, etc.

PNG gana cuando

• El recurso tiene bordes nítidos y regiones de color plano (capturas de pantalla, capturas de interfaz, logotipos, íconos). Los artefactos de pérdida de JPG son muy visibles en estos.
• Se requiere transparencia y WebP no es una opción (incrustación en PDF, algunos flujos de trabajo de impresión).
• El original necesita ser procesado sin pérdida — guardar de nuevo un PNG no lo degrada.

WebP gana cuando

• El destino es la web y los recursos son fotografías o similares a fotografías. Un 25-35% más pequeño que JPG a calidad visual equivalente.
• Necesitas transparencia y el archivo irá en una página web. WebP con pérdida + alpha no tiene igual — PNG con alpha es enorme; AVIF es más pequeño aún pero la compatibilidad es más estrecha.
• Necesitas animación y tu audiencia está en navegadores modernos. La animación WebP es más pequeña y de mayor calidad que el GIF animado.

AVIF gana cuando

• Estás dispuesto a codificar lentamente para mejor compresión. La codificación AVIF puede ser 10-100 veces más lenta que WebP, dependiendo del codificador. La decodificación es rápida.
• La brecha del 7% en compatibilidad de navegadores es aceptable para tu audiencia.
• El peso de la imagen importa desproporcionadamente — imágenes hero en la parte superior en e-commerce, galerías de imágenes, usuarios móviles con conexiones medidas.

El árbol de decisión

1. ¿Necesita renderizarse en cualquier contexto (correo electrónico, lector integrado, impresión)? → JPG para fotos, PNG para gráficos.
2. ¿El destino es estrictamente la web Y tu audiencia es moderna? → WebP o AVIF.
3. ¿Contenido similar a fotografía, destino web, fácil de codificar? → WebP.
4. ¿Contenido similar a fotografía, destino web, sitio con muchas imágenes, dispuesto a codificar lentamente? → AVIF.
5. ¿UI / logotipos / capturas de pantalla? → PNG.
6. ¿Animación? → WebP (o GIF animado solo si es imprescindible).
7. ¿Gráfico vectorial que es un logotipo o ícono? → SVG. No uses un formato rasterizado.
8. ¿Menos de ~10 KB, usado una vez en línea? → URI de datos Base64 con nuestra herramienta de imagen a Base64.

El patrón de respaldo con el elemento picture

Para máxima compatibilidad con tamaño de archivo mínimo, usa el elemento <picture> de HTML con respaldos de formato:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="..." />
</picture>

El navegador elige el primer formato compatible. Chrome moderno obtiene AVIF; Safari 14+ obtiene WebP; el 3% en navegadores antiguos cae de vuelta a JPG. El costo es codificar tres versiones; el beneficio es el formato correcto en cada dispositivo.

Nuestras recomendaciones

• Capturas de pantalla de UI y logotipos: PNG. No lo compliques.
• Fotografías hero: AVIF + respaldo WebP + respaldo JPG vía <picture>.
• Fotos de larga cola e imágenes de blog: WebP, respaldo JPG. AVIF solo si tienes una cadena de construcción que lo produce de manera económica.
• Contenido animado: WebP (o video — a tamaños significativos, un MP4 corto supera a un WebP animado).
• Íconos: SVG.

Usa nuestro cluster de conversores de imagen para los cambios de formato. Cada conversión se ejecuta en tu navegador — sin subidas, sin esperas, sin compromisos de calidad por un servicio del lado del servidor.

Ejemplo resuelto: imagen hero en tres formatos

Fuente: una fotografía de 24 bits de 3000×2000 que pesa 17,4 MB como BMP sin comprimir. Codificada a calidad visualmente equivalente (SSIM ≥ 0,98 frente a la fuente) con la configuración predeterminada del codificador:

• JPG (calidad 82): 612 KB.
• WebP (calidad 80): 388 KB — 37% más pequeño que JPG.
• AVIF (CRF 28): 241 KB — 61% más pequeño que JPG, 38% más pequeño que WebP.
• PNG (sin pérdida): 14,8 MB — 24 veces más grande que JPG, inutilizable como hero web.

Tiempos de codificación en un portátil M2 de 2024 usando libjpeg-turbo,libwebp y libavif respectivamente: JPG 0,08s, WebP 0,34s, AVIF 4,2s. La ralentización de codificación de 50 veces de AVIF es la razón real por la que aún no es el formato predeterminado. Para una cadena de construcción que produce imágenes hero una vez en el momento del despliegue, ese costo se amortiza; para avatares subidos por usuarios redimensionados al vuelo, es prohibitivo.

Errores comunes

• Guardar un JPG repetidamente. Cada guardado recuantiza los coeficientes DCT; la calidad decae aunque la diferencia en pantalla sea invisible al principio. Almacena el original (PNG, TIFF o RAW) y exporta a JPG solo en el momento de publicación. Usa nuestra herramienta PNG a JPG para el paso final.
• Usar PNG-24 donde PNG-8 es suficiente. Una captura de pantalla de una interfaz con 256 colores distintos puede caber en PNG-8 (indexado de 8 bits) a un tercio del tamaño de PNG-24 con salida visual idéntica. La mayoría de los editores de imágenes no usan PNG-8 de forma predeterminada — expórtalo explícitamente para paletas indexadas.
• Omitir el respaldo de <picture>para AVIF. Incluso el 93% de compatibilidad global significa que 1 de cada 14 visitantes obtiene una imagen rota. El respaldo no añade peso para los navegadores que cargan AVIF primero.
• Tratar el modo sin pérdida de WebP como reemplazo de PNG.WebP sin pérdida es excelente para fotografías codificadas sin pérdida; para recursos de UI de color indexado, PNG-8 suele ser más pequeño. Prueba ambos antes de estandarizar.
• Eliminar EXIF e ICC de forma incondicional. El perfil de color (ICC) importa para fotografías vistas en pantallas de gama amplia. Elimina EXIF por privacidad, mantén ICC por fidelidad.

Para las compensaciones del formato de compresión explicadas a nivel de códec, consulta nuestra guía sobre cómo cambiar el tamaño de imágenes sin pérdida de calidad.