Imágenes Open Graph: tamaños, formatos y por qué no aparece la tuya

El estándar 1200×630 y por qué

El estándar de facto og:image el tamaño es 1200×630 píxeles, una relación de aspecto de aproximadamente 1.91:1. Este número no es una tradición arbitraria: se aproxima a la relación de aspecto más ancha con la que se muestran la mayoría de las tarjetas de vista previa de enlaces en Facebook, LinkedIn, Slack y Discord. Por ello, una imagen de 1200×630 llena la tarjeta sin que la plataforma tenga que añadir bandas o recortarla considerablemente.

Las imágenes menores funcionan, pero la plataforma las amplía para llenar la tarjeta y suaviza el detalle, empeorando frente a una preparada expresamente. Muchas plataformas exigen alrededor de 200×200 para aceptar una vista previa: es un mínimo, no un objetivo. Bajar mucho de 1200×630 sacrifica calidad sin beneficio.

De Twitter/X summary_large_image usa la misma imagen de 1200×630 y proporción, así que una suele servir para ambas og:image y twitter:image sin necesitar una exportación separada.

Zona segura: lo que realmente sobrevive al recorte

Incluso con la relación de aspecto correcta, las plataformas recortan la tarjeta de maneras ligeramente distintas según la ubicación: una publicación del feed, una vista previa de enlace en un mensaje directo y un módulo lateral de «enlaces compartidos» no siempre usan el mismo recorte. Un texto o logotipo pegado al borde puede cortarse en una ubicación aunque se viera bien en la vista previa de tu navegador.

Deja lo esencial —titular, logotipo, rostro— aproximadamente en el 90% interior, con margen del 5–10% en cada borde. Fondos, degradados y adornos pueden ir hasta el borde; lo imprescindible debe quedar dentro. Una guía a unos 60px de cada lado en un lienzo de 1200×630 da un área segura razonable.

Formato: JPG o PNG y por qué no WebP

Para el archivo de imagen real, JPG y PNG son las opciones seguras. La compatibilidad con WebP para og:image en particular varía entre rastreadores y bots: algunos admiten WebP y otros fallan sin aviso. Es fácil publicar una vista previa rota sin descubrirlo hasta que alguien lo dice.

Esto exige más compatibilidad que servir WebP a un navegador, algo que casi todos los actuales gestionan bien; consulta nuestra Comparación de WebP, PNG y JPG para el caso general. Los rastreadores de enlaces son más conservadores que los navegadores y van atrás con WebP. Usa JPG para fotos y PNG para colores planos, texto o transparencia, aunque en OG el alfa siempre se compone sobre el fondo de la tarjeta.

La mayoría de las plataformas acepta técnicamente GIF como imagen estática, pero no es una opción útil para una vista previa fotográfica o con mucho diseño; no hay ninguna razón práctica para usarlo aquí en lugar de JPG o PNG.

La URL debe ser absoluta

<meta property="og:image" content="/og-image.jpg" /> parece razonable y funciona al abrir directamente porque el navegador resuelve la ruta contra la URL de la página. Los rastreadores no siempre lo hacen bien o usan otra base: la imagen falla en unas plataformas y funciona en otras, dificultando diagnosticar solo con avisos de usuarios.

Escribe siempre la URL absoluta completa, incluidos el esquema y el dominio:

<meta property="og:image" content="https://example.com/og-image.jpg" />

En la API Metadata de Next.js, esto significa configurar metadataBase en el layout raíz para resolver rutas relativas de metadatos como URL absolutas al compilar, o escribe la URL completa en los openGraph.images como hace este sitio.

Caché: por qué una imagen corregida sigue mostrando la vista previa antigua

Es la causa más frecuente de «lo arreglé y sigue mal». Las plataformas guardan Open Graph, incluida la imagen, por URL; desplegar otro archivo no vacía esa caché. Recargar, incluso en privado, no dice qué conserva la plataforma.

Cada plataforma principal tiene su propia herramienta para forzar una nueva lectura:

• Facebook / Meta: Sharing Debugger (developers.facebook.com/tools/debug/): pega la URL y pulsa «Scrape Again». También vacía la caché de Instagram y WhatsApp, que comparten rastreador Meta.
• X/Twitter: Card Validator ha cumplido esa función; su disponibilidad cambia. Si no responde, añade una consulta de versión inofensiva a la URL como alternativa fiable.
• LinkedIn: Post Inspector (linkedin.com/post-inspector/): pega la URL para forzar una nueva lectura.
• Slack, Discord, iMessage: no hay depurador público. Suelen caducar su caché con su propio calendario o actualizar si cambia ligeramente la URL.

Si un depurador de una plataforma no está disponible o no responde, la solución universal es cambiar la URL que ve la plataforma, añadiendo una consulta de versión como ?v=2 al enlace o URL de imagen obliga a tratarlo como recurso nuevo y obtenerlo, en vez de servir caché antigua.

Tamaño de archivo y otros límites

La mayoría de las plataformas documenta límites de unos pocos megabytes: el de Facebook ha rondado históricamente 8MB. Incluso sin cifra publicada, un archivo inusualmente grande puede agotar el tiempo o no generar vista previa. Un JPG o PNG de 1200×630 bien comprimido suele quedar muy por debajo de 500KB; alcanzar el límite casi siempre indica una exportación sin optimizar: una foto enorme reducida solo en el marcado, sin recodificarla a dimensiones menores, o una foto exportada a PNG en vez de JPG. Consulta nuestra guía para reducir el tamaño de archivo de imágenes para el enfoque general de reducir una exportación sin pérdida visible de calidad.

Legibilidad del texto en miniatura

Una imagen OG suele mostrarse mucho más pequeña que sus 1200×630 píxeles originales: una vista previa de Slack o una tarjeta de feed móvil puede tener unos pocos cientos de píxeles de ancho. Cualquier texto incorporado a la imagen debe seguir siendo legible tras esa reducción. Como orientación práctica, un texto de cuerpo inferior a unos 40 px en el ancho original de 1200 px tiende a volverse ilegible al reducirlo para las ubicaciones habituales del feed; un título que deba leerse como miniatura suele necesitar un tamaño mucho mayor, alrededor de 60–80 px o más, en negrita y con gran contraste respecto al fondo.

También conviene simplificar la imagen. Una composición con varios textos puede funcionar a tamaño completo y volverse ruido en tarjeta. Un titular claro sobre fondo contrastado se lee de forma fiable en todos los lugares.

twitter:card necesita su propia declaración

Ajuste og:image no basta automáticamente para una vista previa grande en X/Twitter. El sistema de tarjetas lee su propio twitter:card etiqueta meta para decidir el estilo; sin ella, algunos clientes de Twitter usan tarjeta de miniatura pequeña aunque haya una perfectamente válida og:image está presente.

Decláralo explícitamente:

<meta name="twitter:card" content="summary_large_image" />

Twitter usará como alternativa og:image para la imagen real si twitter:image no se configura aparte, así que no suele hacer falta repetir URL. La declaración de tipo de tarjeta sí es obligatoria para el diseño de imagen grande.

Un orden rápido de diagnóstico

1. Confirma que la URL de la imagen sea absoluta, no relativa, y que cargue directamente en un navegador.
2. Confirma que el formato sea JPG o PNG, no WebP.
3. Confirma que las dimensiones sean 1200×630 o similares.
4. Confirmar twitter:card está configurado si falla específicamente la vista previa de Twitter/X.
5. Usa el depurador de la plataforma para forzar una nueva lectura antes de suponer que la solución falló.
6. Si no hay depurador disponible, cambia un parámetro de versión de la URL para evitar la caché.

Preguntas frecuentes