Open Graph image

Overview of required vs optional Open Graph tags for social link previews, with emphasis on image metadata.

Open Graph metadata establishes the content used by link preview crawlers. The protocol itself does not mandate any property as strictly required, but most platforms expect, at minimum, og:title, og:type, og:url, and og:image for a compelling preview. The image property points to a fully qualified URL and often determines whether a large or compact preview is rendered. Image-related auxiliary properties—width, height, MIME type, and alternative text—improve reliability, reduce crawler guesswork, and support accessibility-aware clients.

Multiple og:image tags are allowed, which can help platforms choose the best fit for their layouts or device classes. Some crawlers select the first valid image; others consider declared dimensions to pick an optimal candidate. Declaring og:image:secure_url (HTTPS) avoids mixed-content issues. Although many platforms can infer width, height, and type by fetching the asset, explicitly setting og:image:width, og:image:height, and og:image:type tends to reduce mis-crops, delays, or fallbacks to a smaller preview.

• Core preview set: og:title, og:type, og:url, og:image
• Image-specific helpers: og:image:secure_url, og:image:type, og:image:width, og:image:height, og:image:alt
• Multiple images permitted; order can imply preference

Cross-platform baseline

Preview renderers across Facebook, LinkedIn, X (Twitter), Pinterest, Slack, Discord, WhatsApp, iMessage, and Microsoft Teams vary in feature support and image crops. A conservative baseline that travels well uses a 1.91:1 aspect ratio (commonly 1200 × 630 or 1200 × 628), JPEG for photographic content or PNG for flat graphics, and a file size kept modest for faster scraping. An absolute HTTPS URL, correct Content-Type headers, and declared width/height offer the most consistent outcomes. Where supported, og:image:alt provides a text alternative for assistive technologies and low-vision users.

Square images (1:1) can also render predictably in many contexts, though some platforms still favour 1.91:1 for large cards. Animated formats are inconsistently supported in preview cards and are often flattened to a static frame. SVG files are commonly ignored for previews. Because platforms cache aggressively, a stable, versioned image URL improves refresh control while avoiding broken previews during deployments.

• Safe aspect ratios: 1.91:1 (1200 × 630/628) or 1:1 (at least 600 × 600)
• Formats: JPEG for photos; PNG for logos/illustrations; avoid SVG; animated GIF/WebP not reliably animated in cards
• Alt text: og:image:alt improves accessibility in some clients
• Use absolute HTTPS URLs; declare width, height, and type

Scope and support

Open Graph is a de facto standard for link unfurling, adopted by major social networks and messaging platforms, as well as by many enterprise collaboration tools. Some platforms extend or override OG with their own tags (for example, Twitter Cards), yet most fall back to OG when platform-specific tags are missing. Google Search does not use Open Graph for ranking, and thumbnails in search results are governed by different systems (e.g., structured data, on-page images, and Google’s own heuristics), so the OG image primarily affects social and messaging contexts rather than organic SERPs.

Crawlers vary in how often they recrawl and how strictly they follow robots controls or HTTP caching. Many will respect long cache lifetimes and reuse previously fetched images; others may refetch after a share event or when content appears to change. Access restrictions, hotlink protections, and geo-blocking can prevent crawlers from loading images, resulting in downgraded previews. Reliable previews assume openly accessible images, accurate headers, and consistent uptime from the image host or CDN edge.

Overview

The Open Graph image is part of a broader preview payload that typically includes title, description, and canonical URL. During scraping, a platform fetches the HTML, extracts OG properties, and retrieves the image before composing a preview card. Declared dimensions let the platform reserve layout space while the image downloads, which can reduce flashes of empty space and improve unfurl speed. When multiple images are provided, platforms may prefer the first valid one, or the image whose dimensions best match the card layout. Fallback behaviour—such as using an in-page image or a logo—varies by platform.

From a performance perspective, OG images are fetched by bots rather than end users during page load, so they typically do not affect page rendering metrics like LCP or CLS. However, they do affect crawler latency, server egress, and cache utilisation, especially on high-traffic content. Using a CDN, keeping file sizes moderate, and providing stable versioning helps reduce scrape times and broken previews. Content quality remains pivotal: images with clear focal points, legible text overlays, and strong contrast tend to be more effective in crowded social feeds.

CTR and engagement impact

Link previews compete for attention in visually dense feeds. A well-composed Open Graph image can increase click-through rate, dwell time on the landing page, and shareability, although the scale of improvement varies by audience, platform, and creative treatment. Images that convey context quickly, avoid cramped details, and are recognisable at small sizes perform more reliably across mobile and desktop surfaces. Overlaid text should remain legible within expected crops, and important content should avoid the edges where some platforms apply trims or rounded corners.

Brand systems benefit from consistent framing, colour, and graphic motifs carried across OG images. For campaigns, A/B testing different visuals on the same landing page—using versioned image URLs to force platform cache refresh—can reveal preferences by network. While metrics available from social platforms vary, trends generally show higher engagement for images with clear subjects, human elements, and high contrast, whereas generic stock imagery and low-resolution crops underperform.

• Prioritise clarity and focal point over dense detail
• Keep critical text away from edges to survive crops
• Maintain brand consistency across multiple share surfaces

Implementation notes

Tagging and URLs

Use absolute HTTPS URLs for og:image and consider og:image:secure_url for clients that enforce secure assets. Provide og:image:type with a conventional MIME (image/jpeg or image/png) and declare og:image:width and og:image:height to assist pre-layout. Multiple og:image tags can express fallbacks (e.g., 1200 × 630 JPEG, then a square PNG), but order them by preference. Ensure images are publicly fetchable without authentication, user-agent blocking, or referer gating.

File handling and delivery

Host OG images on a performant CDN with correct Content-Type, Content-Length, and cache headers. A long max-age with a versioned filename or query string allows deliberate refreshes without breaking cached shares. Avoid heavy images that slow scrapes; while caps differ by platform, keeping files comfortably under a few megabytes reduces timeouts and bandwidth. Optimise colour profiles to sRGB and flatten transparency where possible to prevent unpredictable dark or light backgrounds in cards.

Cache refresh and validation

Previews are cached. To propagate updates, issue a new versioned image URL or trigger re-scrapes using each platform’s debugger tools (e.g., sharing debuggers and post inspectors). Expect caches to persist from hours to days depending on platform behaviour. Validate that the image is reachable, headers are correct, and metadata parses as intended using the same tools. For localisation or multivariate campaigns, generate stable, per-locale image URLs to minimise cache collisions.

Comparisons

Open Graph image vs Twitter Card image

Twitter Cards use twitter:image (and optionally twitter:image:alt) alongside OG. When both sets are present, Twitter/X tends to prefer its own tags; otherwise it falls back to og:image. Dimensions are similar (commonly 1200 × 628), but card types (summary_large_image vs summary) govern rendering and crops. Providing both OG and Twitter tags improves fidelity across more clients, especially where Twitter-specific behaviour differs from other networks.

Open Graph image vs schema.org image

Schema.org properties like image or thumbnailUrl serve structured data for search engines and rich results, while og:image targets social previews. Search engines generally do not use OG to populate rich snippets, and social platforms generally ignore schema.org for unfurling. Sites concerned with both social sharing and search presentation typically publish both sets: OG for previews and structured data for Search features.

FAQs

Can WebP or AVIF be used for og:image?

Support for newer formats in link previews is inconsistent. Some platforms can fetch WebP and convert it server-side, but others ignore it or render fallbacks. AVIF support is more limited. JPEG and PNG remain the most reliably accepted for preview cards. Where modern formats are desired, provide a conservative JPEG/PNG as the primary og:image and experiment with additional variants only if analytics confirm consistent rendering.

What size should the Open Graph image be?

A common recommendation is 1200 × 630 (approximately 1.91:1) for widescreen cards, with square alternatives supported by many clients. Minimums vary by platform, but images smaller than a few hundred pixels per side risk small or no image treatment. File sizes under a few megabytes limit crawler timeouts and bandwidth use. Declaring og:image:width and og:image:height helps renderers reserve the correct layout and avoid incorrect crops during loading.

Can a page include multiple og:image tags, and how are they used?

Yes. The protocol allows multiple images, and platforms typically choose the first valid image or the one whose declared dimensions best fit their card layout. Provide accurate width/height for each image. Some platforms expose a carousel to choose among images during manual sharing, but automated unfurls generally pick a single image based on precedence and suitability.

How can stale previews be refreshed after changing the image?

Because previews are cached, updates may not appear immediately. Issuing a new, versioned image URL (e.g., a query string with a build hash) forces most platforms to fetch the new asset. Alternatively, use platform tools such as sharing debuggers and post inspectors to trigger a rescrape of the page. Cache lifetimes vary by platform and can range from hours to days.

Does the Open Graph image affect SEO rankings in Google Search?

No. Open Graph properties are not ranking signals for Google Search. They influence social and messaging previews rather than organic rankings. For search thumbnails and rich results, structured data (schema.org), on-page images, and overall page quality are more relevant. While OG images can increase traffic via higher social CTR, that effect is indirect from an SEO standpoint.