Formatos de imagen para SEO: JPEG vs. PNG vs. WebP vs. AVIF

Análisis profundo de la comparación de formatos para el SEO de imágenes: compresión, transparencia, animación y compatibilidad de navegadores en 2026 para JPEG, PNG, WebP, AVIF, SVG y GIF, además del mito desmontado: el formato no mejora el posicionamiento, solo la velocidad.

Publicado por primera vez: 2 jul 2026 · Última actualización: 22 ago 2026 · Avanzado
Idiomas

La elección del formato de imagen (JPEG, PNG, WebP, AVIF, SVG, GIF) no tiene peso directo en el posicionamiento: John Mueller, de Google, ha confirmado que no existe ninguna mejora de SEO por usar WebP o AVIF frente a JPEG/PNG. La ganancia es enteramente indirecta: el formato adecuado reduce el tamaño del archivo, los archivos más pequeños cargan más rápido, las cargas más rápidas mejoran Largest Contentful Paint y Core Web Vitals, y eso es lo que usan realmente los sistemas de posicionamiento. Por tanto, el formato importa enteramente a través de la cadena de velocidad, no por sí mismo. Elige según el tipo de contenido: WebP es la opción moderna segura para fotos (~96 % de compatibilidad, ~25–35 % más pequeño que JPEG); AVIF comprime más (~50 % más pequeño que JPEG, ~94 % de compatibilidad en 2026), pero cuesta más codificar y no tiene renderizado progresivo; PNG para transparencia y gráficos de bordes nítidos; SVG para logotipos e iconos; GIF solo como fallback universal de animación. Sirve los formatos modernos con un fallback <picture>: ese src de fallback es la URL que indexa Google. Este es el análisis profundo de formatos; la guía de implementación está en Image Optimization.

TL;DR — El formato de imagen no es un factor de posicionamiento. John Mueller, de Google, ha confirmado que no existe ninguna mejora de SEO por usar AVIF, y que WebP solo es “fine for Image Search”; es un lenguaje deliberadamente neutro, no significa «mejor». La cadena real es: formato → tamaño del archivo → velocidad de la página → Largest Contentful Paint / Core Web Vitals → las señales de experiencia de página que usan realmente los sistemas de posicionamiento. El formato está varios pasos antes. Elige por tipo de contenido, no porque «lo nuevo siempre gana»: WebP es la opción segura para fotos (~96 % de compatibilidad, ~25–35 % más pequeño que JPEG y admite transparencia alfa incluso en modo con pérdida; JPEG no); AVIF comprime más (~50 % más pequeño que JPEG, ~94 % de compatibilidad en 2026), pero exige más CPU para codificar y no tiene renderizado progresivo; PNG para transparencia y gráficos o texto con bordes nítidos; SVG para logotipos, iconos y diagramas; GIF solo como fallback universal para animaciones. Sirve los formatos modernos mediante <picture> (AVIF → WebP → JPEG/PNG src): el src de fallback es la URL que indexa Google. Este es el análisis profundo de formatos; la implementación de LCP/fetchpriority/carga diferida está en Image Optimization.

Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats Evidence for this claim Format choice should reflect image characteristics and browser support; modern formats can improve compression but require deliberate encoding and fallbacks where needed. Scope: Current Chrome/web.dev image format guidance. Confidence: high · Verified: web.dev: Choose the right image format

¿Afecta realmente el formato de imagen al SEO?

Empieza desmontando el mito, porque es la razón por la que la mayoría de la gente llega a esta página.

El formato no es un factor de posicionamiento. John Mueller lo ha dicho al menos de tres formas distintas y en momentos independientes, pero el hilo conductor siempre es el mismo: el formato no es una señal; lo es la velocidad que permite. Tras el anuncio de Google de agosto de 2024 de que AVIF ya era compatible con Search, Mueller confirmó que no hay ninguna «mejora de SEO» por usar AVIF frente a otros formatos compatibles (la cobertura de Search Engine Roundtable); el beneficio es reducir el tamaño del archivo, lo que puede ayudar a la velocidad de la página, no crear una preferencia de posicionamiento por el contenedor. Años antes, con WebP, eligió sus palabras con el mismo cuidado: “WebP images are fine for Image Search” (traducción) «Las imágenes WebP sirven perfectamente para la búsqueda de imágenes» (SE Roundtable); dijo que sirven, no que sean mejores ni preferidas. Y cuando las imágenes WebP empezaron a aparecer en el informe «Rastreada: actualmente sin indexar» de Search Console, Mueller aclaró que se trata de una peculiaridad general de los informes de imágenes (las imágenes no se indexan como páginas HTML), no de una desventaja específica de WebP: “he doesn’t believe the phenomenon is limited to WebP images” (traducción) «no cree que el fenómeno se limite a las imágenes WebP» (el artículo de Search Engine Journal).

El documento principal de Google sobre SEO de imágenes también lo confirma por omisión: enumera los formatos compatibles, te dirige a PageSpeed Insights para el rendimiento y nunca relaciona la elección del formato con un factor de posicionamiento. Esa ausencia es una prueba en sí misma.

Este es el mismo mito que desmonto en el nivel central de Image SEO y en la guía de implementación, Image Optimization, y merece expresarse con precisión. No digas «el formato no importa». Di «el formato no importa directamente: importa por completo a través de la cadena de velocidad y Core Web Vitals».

La cadena real: formato → tamaño del archivo → velocidad → Core Web Vitals

Esta es la secuencia causal, paso a paso, porque precisamente colapsarla es lo que propaga el mito:

  1. La elección del formato cambia el tamaño del archivo. Es la palanca individual más importante sobre el peso de una imagen.
  2. Los archivos más pequeños cargan más rápido. El propio documento de imágenes de Google señala que las imágenes son “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traducción) «a menudo el mayor componente del tamaño total de una página, lo que puede hacer que las páginas sean lentas y costosas de cargar».
  3. Las cargas más rápidas mejoran Largest Contentful Paint (LCP). La imagen principal suele ser el elemento LCP, así que su peso mueve directamente la métrica. (Lo explico a fondo en mi guía sobre Largest Contentful Paint, en la parte que explica por qué LCP suele ser una imagen).
  4. LCP alimenta Core Web Vitals, que sí forma parte de las señales de experiencia de página que usan los sistemas de posicionamiento de Google.

El formato está al principio de esa cadena, varios pasos antes de cualquier aspecto relacionado con el posicionamiento. Esa es precisamente la razón por la que no es un factor de posicionamiento por sí solo: entre ambos puntos tienen que salir bien demasiadas cosas, y si la página no se vuelve realmente más rápida, nada cambia después.

Comparación de los seis formatos

La mayoría de las «guías de 2026» de la competencia solo cubren JPEG/PNG/WebP/AVIF y presentan discretamente mal las cifras de compatibilidad de los navegadores (he visto citar AVIF en «~74 %», una cifra desactualizada desde hace años). Aquí tienes la matriz completa de seis formatos con cifras actuales.

FormatoCompresiónTransparenciaAnimaciónCompatibilidad de navegadores (2026)Uso habitual
JPEGSolo con pérdidaNoNoUniversalFotografías; el fallback universal
PNGSolo sin pérdidaSí (alfa completa)No (APNG es una extensión independiente y menos compatible)UniversalCapturas, logotipos, gráficos de bordes nítidos, texto en imágenes y cualquier caso que necesite transparencia sin el riesgo de un formato moderno
WebPCon y sin pérdidaSí (alfa incluso en modo con pérdida)~96 % global; universal desde ~2020Opción moderna segura para fotos; ~25–35 % más pequeño que JPEG; WebP sin pérdida ~26 % más pequeño que PNG
AVIFCon y sin pérdidaSí (Chrome/Edge/Safari 16.4+; todavía no Firefox)~94 % globalMáxima compresión con fallback; ~50 % más pequeño que JPEG; admite HDR / gama cromática amplia
SVGN/A (vectorial, no rasterizado)Sí (mediante CSS/SMIL/JS)UniversalLogotipos, iconos, diagramas y arte lineal: escala sin perder calidad
GIFSin pérdida (LZW), máximo 256 coloresSí (solo binaria, sin alfa parcial)UniversalAnimaciones sencillas heredadas; el fallback de animación más compatible
Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats
Las cifras de compatibilidad reflejan caniuse.com a mediados de 2026 (AVIF ~94 % global, WebP ~96 %); estos porcentajes suben continuamente, así que vuelve a verificarlos en caniuse.com/avif y caniuse.com/webp antes de basarte en ellos.

JPEG: el fallback fotográfico universal

Solo con pérdida, sin transparencia ni animación, y compatible literalmente en todas partes. JPEG sigue siendo el fallback correcto al final de un elemento <picture> y una opción perfectamente válida para fotografías cuando no las conviertes a un formato moderno. Su punto débil está incorporado en el funcionamiento de la compresión con pérdida: según el equipo de Chrome de Google en web.dev, “lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.” (traducción) «la compresión con pérdida puede ser menos eficaz con imágenes que contengan bordes definidos, como ilustraciones lineales, detalles igualmente marcados o texto». Precisamente por eso JPEG es una mala elección para logotipos, capturas y gráficos con mucho texto: se ven los artefactos.

PNG: sin pérdida, transparencia, gráficos y capturas

Sin pérdida y con transparencia alfa completa. PNG es adecuado cuando necesitas bordes nítidos (logotipos, capturas de interfaz, texto en imágenes) o un fondo transparente y no quieres asumir la complejidad de los fallbacks de los formatos modernos. El coste: para las fotografías, PNG produce archivos innecesariamente enormes sin una mejora visible de calidad frente a un JPEG/WebP bien ajustado; estás pagando la ausencia de pérdida para nada en una foto. (APNG existe para PNG animado, pero es una extensión distinta y menos compatible; no conviene apoyarse en ella.)

WebP: la opción moderna segura

WebP es el formato que elegiría primero para la mayoría de las fotos web. El equipo de Chrome de Google explica directamente por qué: “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (traducción) «WebP suele comprimir mejor que JPEG, PNG o GIF y ofrece compresión tanto con pérdida como sin pérdida». También elimina la principal limitación de JPEG: “WebP also supports alpha channel transparency even when using lossy compression — a feature the JPEG codec doesn’t offer.” (traducción) «WebP también admite transparencia mediante canal alfa incluso con compresión con pérdida, una función que el códec JPEG no ofrece». La compatibilidad no supone un problema: web.dev lo llama “a widely supported format that works on all modern browsers” (traducción) «un formato ampliamente compatible que funciona en todos los navegadores modernos» (~96 % global en 2026). Es aproximadamente un 25–35 % más pequeño que JPEG con una calidad similar, y WebP sin pérdida ocupa ~26 % menos que PNG. Si vas a convertir una sola cosa, convierte tus fotos a WebP.

AVIF: la mejor compresión, con costes reales

AVIF gana en compresión bruta. Según web.dev, “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases,” (traducción) «AVIF admite compresión con y sin pérdida, y las pruebas han mostrado ahorros superiores al 50 % frente a JPEG en algunos casos», además de ofrecer “Wide Color Gamut (WCG) and High Dynamic Range (HDR) features.” (traducción) «funciones de amplia gama de colores (WCG) y alto rango dinámico (HDR)». En 2026, su compatibilidad de navegadores ronda el ~94 % global: Chrome (desde 2020), Firefox (2021), Safari (16.4+, desde 2023) y Edge (121+, enero de 2024) lo muestran. Está listo para producción, con un fallback.

Pero «la mejor compresión» no es la única variable, y ser sincero sobre los costes de AVIF es lo que separa una guía útil de una lista superficial:

  • La codificación exige mucha CPU. AVIF tarda en producirse, algo importante para grandes bibliotecas multimedia y pipelines de CMS que vuelven a codificar miles de recursos.
  • No hay renderizado progresivo. Según MDN, un AVIF debe descargarse por completo antes de mostrarse, a diferencia de un JPEG progresivo que primero pinta una versión de baja resolución. En una conexión lenta puede sentirse peor pese a que el archivo sea más pequeño.
  • Las herramientas para AVIF animado aún están inmaduras. El formato admite animación (a veces llamada AVIS), y Chrome, Edge y Safari 16.4+ pueden reproducirla, pero Firefox todavía no puede hacerlo en 2026, y las herramientas de producción van por detrás de las de GIF/WebP animados.

SVG: gráficos vectoriales, iconos, logotipos y diagramas

SVG es distinto: es vectorial, se describe con matemáticas en lugar de una cuadrícula de píxeles, así que escala a cualquier tamaño sin perder calidad y sigue siendo pequeño para formas sencillas. La regla práctica de web.dev es que los SVG son “most useful in cases where the image’s contents are line art, diagrams and charts, and other cases where there aren’t fine photographic details.” (traducción) «especialmente útiles cuando la imagen contiene ilustraciones lineales, diagramas, gráficos u otros elementos sin detalles fotográficos finos». Los logotipos, iconos y diagramas pertenecen a SVG, sin más. No lo uses para fotografías: no está diseñado para ellas.

Hay algo que hace que SVG sea realmente distinto de los otros cinco formatos: es XML, no datos de píxeles, y según la referencia de MDN un archivo SVG puede contener scripts y referenciar recursos externos. MDN señala específicamente que “there are additional restrictions when SVG is used” (traducción) «se aplican restricciones adicionales cuando se usa SVG» como una imagen normal (mediante <img> o CSS background-image) frente a su inserción en línea o mediante un <iframe>/<object>. Esa restricción existe porque un SVG cargado como una «imagen» normal está aislado para impedir que ejecute scripts o recupere recursos externos, precisamente para cerrar un vector XSS. Si aceptas cargas SVG de usuarios (una biblioteca de iconos o un formulario para subir logotipos), sanitízalas antes de servirlas: elimina las etiquetas <script> y las referencias externas, igual que tratarías cualquier otro marcado proporcionado por un usuario, no como tratarías un JPEG.

GIF: animación heredada, cuando sigue siendo la opción correcta

GIF usa compresión LZW sin pérdida, limitada a una paleta de 256 colores, con transparencia únicamente binaria (activada o desactivada). Es el formato histórico de animación y, para cualquier cosa no trivial, ha sido sustituido por WebP/AVIF animados (o, mejor aún, vídeo). Su única ventaja restante es la compatibilidad universal: si necesitas que una animación sencilla se reproduzca en todas partes sin ninguna lógica de fallback, GIF sigue siendo el mínimo común denominador. En los demás casos, elige WebP animado.

Uses el formato de animación que uses, trata la semántica por separado de la decisión de formato: un GIF o una imagen animada en bucle que transmita información necesita texto alternativo que describa lo que muestra, igual que una imagen estática, y un bucle puramente decorativo debe marcarse como tal en lugar de leerse como contenido mediante un lector de pantalla. Ninguna de esas dos cuestiones depende de la compatibilidad del formato: se aplican tanto si sirves GIF como WebP o AVIF animados.

¿Qué formato deberías usar realmente?

Haz coincidir el formato con el contenido, no con «cuál es el más nuevo». La pestaña del árbol de decisión lo explica como un flujo, pero esta es la versión breve:

  • Fotografías → WebP (opción segura) o AVIF con fallback JPEG si quieres la máxima compresión.
  • Logotipos, iconos, diagramas y arte lineal → SVG.
  • Capturas, gráficos con bordes o texto nítidos y cualquier imagen que necesite transparencia sin la complejidad de un fallback → PNG (o WebP sin pérdida).
  • Animación sencilla → WebP/AVIF animado cuando sea compatible; GIF solo como fallback universal. (Para cualquier cosa más rica, usa vídeo.)

Una salvedad honesta sobre todos los porcentajes de compresión de este artículo: son cifras representativas de las pruebas de web.dev y caniuse, no una garantía para tus imágenes. El ahorro depende del contenido de la imagen original (una foto recargada se comprime de forma distinta que un gráfico de color plano) y de los ajustes del codificador que uses. Trata «WebP es ~25–35 % más pequeño» y «AVIF es ~50 % más pequeño» como una expectativa inicial y compara después tus propias codificaciones con los ajustes de calidad que realmente vayas a publicar: es la única forma de saber qué consigue un cambio de formato concreto en tus páginas.

Implementación segura de formatos modernos: el fallback de <picture>

No sirvas formatos modernos solos: sírvelos con fallbacks. El patrón limpio es un elemento <picture> que ofrece primero AVIF, después WebP y termina en un <img src> normal que apunte a un JPEG o PNG:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Descriptive alt text" width="1200" height="800" />
</picture>

El navegador elige el primer formato que entiende; los navegadores antiguos y algunos rastreadores llegan al src. Hay dos cosas que conviene interiorizar: ese src de fallback es la URL que Google indexa realmente para la búsqueda de imágenes (Google analiza el <img> incluso cuando está dentro de <picture>, pero no indexa background-image de CSS), y aquí es donde la elección del formato da paso al trabajo de implementación más amplio: dimensiones, ajustes de compresión, srcset/sizes, carga diferida y fetchpriority en la imagen LCP. Esa guía completa no se duplica aquí: está en Image Optimization, y la mecánica de servicio adaptativo (srcset, sizes y dirección artística) está en Responsive Images.

Compatibilidad oficial de Google y Bing

Lista de formatos compatibles de Google y el hito de AVIF de agosto de 2024

La lista de formatos compatibles de Google Search es explícita: “Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (traducción) «Google Search admite imágenes referenciadas en el atributo src de img en los formatos BMP, GIF, JPEG, PNG, WebP, SVG y AVIF» (además de los URI de datos Base64). AVIF es la incorporación más reciente, y la fecha importa: Google no admitió AVIF en Search en absoluto hasta el 30 de agosto de 2024, cuando anunció que “AVIF is now a supported file type in Google Search” (traducción) «AVIF es ahora un tipo de archivo compatible con Google Search» y que “you don’t need to do anything special to have your AVIF files indexed.” (traducción) «no necesitas hacer nada especial para que se indexen tus archivos AVIF». Antes de esa fecha, AVIF no estaba en la lista y, según la cobertura de terceros, usar miniaturas AVIF podía incluso hacer que Google cancelara por completo la indexación de vídeos. Es una línea temporal realmente reciente y fechable: cualquier guía de la competencia escrita antes de mediados de 2024 y nunca actualizada ofrece consejos obsoletos sobre la seguridad de AVIF.

Observa cómo presentó Google el anuncio: únicamente como “we can now process this file type,” (traducción) «ahora podemos procesar este tipo de archivo», nunca como el lanzamiento de una señal de posicionamiento. Es el mismo encuadre no relacionado con el posicionamiento que aparece en el resto de la lista de formatos, y por eso el titular de Search Engine Journal «El nuevo soporte de Google para imágenes AVIF podría mejorar el SEO» es un buen ejemplo de advertencia: el cuerpo dirige correctamente la «mejora» por completo a través de tamaño del archivo → Core Web Vitals, pero el titular es exactamente la forma en que la prensa del sector, aunque tenga buenas intenciones, amplifica el mito de que formato equivale a posicionamiento.

La orientación pública (limitada) de Bing

Bing no publica un documento comparativo formato por formato como el de Google. Sus directrices generales para webmasters consideran la velocidad de la página —incluido el peso de las imágenes—, pero no existe una página técnica específica de Bing que diga «usa WebP/AVIF», y no voy a inventarla. Bing indexa y muestra imágenes JPEG/PNG/WebP/GIF en Bing Images sin problemas; en general se supone que la compatibilidad de su rastreador con los formatos modernos sigue la de los navegadores cercanos a Chromium, pero, a diferencia de Google, no está documentada por separado. Este es el mismo vacío honesto que señalo en Image Optimization: lo expreso claramente en lugar de ocultarlo.

Mitos comunes sobre formatos de imagen y SEO

  • «Cambiar a WebP/AVIF mejora el posicionamiento». No: Mueller lo ha dicho directamente: no hay mejora de SEO por AVIF; WebP está «fine», no es «better». El beneficio es indirecto, mediante tamaño del archivo → velocidad → Core Web Vitals.
  • «AVIF siempre es mejor porque comprime mejor». Es una exageración. AVIF exige mucha CPU para codificar, no tiene renderizado progresivo y Google Search no lo admitió hasta agosto de 2024. La mejor compresión no es la única variable.
  • «PNG siempre es la opción segura y de alta calidad». Falso como regla general. PNG es adecuado para gráficos, transparencia y texto, pero genera archivos enormes para fotografías y perjudica la velocidad de carga sin una ganancia visible.
  • «Ya no necesitas un fallback: la compatibilidad es prácticamente universal». Es mayormente cierto para WebP, pero sigue mereciendo la pena usar un fallback <picture> para AVIF por la brecha real (aunque pequeña) de ~6 %, además de los casos límite de rastreadores y dispositivos antiguos. Google recomienda explícitamente el patrón con fallback.
  • “Google penalizes older formats like JPEG/PNG.” (traducción) «Google penaliza formatos antiguos como JPEG/PNG». Falso: JPEG, PNG, GIF y BMP siguen siendo totalmente compatibles. No hay penalización, solo una oportunidad de velocidad perdida frente a los formatos modernos.
  • «AVIF no puede animarse / WebP no admite transparencia». Ambas afirmaciones son falsas. WebP admite transparencia alfa incluso en modo con pérdida; AVIF admite animación (Safari 16.4+, Chrome y Edge, aunque Firefox todavía no en 2026).
  • «AVIF no está listo: seguimos en un mundo solo de WebP». Desactualizado. AVIF ronda el ~94 % de compatibilidad global y Google Search puede indexarlo desde agosto de 2024. Trátalo como listo para producción con fallback, no como experimental.
Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats

Dónde encaja esto

Este artículo es el análisis profundo de comparación de formatos dentro del clúster de Image SEO: es el hogar canónico de la matriz de seis formatos y del desmontaje del mito de posicionamiento. Sus dos artículos hermanos cubren las tareas adyacentes: Image Optimization es la guía de implementación (LCP, fetchpriority, carga diferida, compresión y dimensiones), y Responsive Images cubre la mecánica de srcset/sizes/<picture> para servir el tamaño adecuado según el dispositivo. El beneficio de rendimiento de elegir bien el formato es, en realidad, una historia de Core Web Vitals con una imagen como protagonista.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.