PreviewChecks

Put the safest Open Graph image first

Open Graph allows more than one image, but order is part of the data. The protocol gives the first value preference when repeated properties conflict, so the first image should be the one you trust across the broadest set of link cards.

Start with one complete image block

Put the root og:image property first, then place its structured properties directly after it. This keeps width, height, MIME type and alternative text attached to the right image when a parser reads the tags from top to bottom. 

<meta property="og:image" content="https://example.com/share/page-v3.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:alt" content="A concise description of the image">

Use an absolute HTTPS URL. The dimensions and type are declarations, not a substitute for the real response: the file still needs to return those bytes and that content type.

Choose the first image for compatibility

A wide image near 1.91:1, commonly 1200x630, is a practical first candidate for Open Graph-style link cards. It leaves enough resolution for large cards and avoids forcing a portrait crop on services that display a wide preview.

That does not mean every platform has one universal requirement. X, Facebook, LinkedIn, chat apps and Pinterest can crop, contain or select images differently. Treat a loadable wide image as the compatibility baseline, then read platform-specific crop and optimization notes separately.

Keep important text and faces away from the outer edges. A platform can change the visible crop by surface, screen size or card type even when the original ratio is accepted.

Test the URL, not only the markup

  1. 1. Follow the complete redirect chain

    Prefer a direct image URL. If an optimizer redirects it, verify every hop and the final HTTPS response. A redirect can introduce a different host, certificate, WAF rule or cache policy.

  2. 2. Verify the actual image response

    Check status, MIME type, file size and decoded dimensions. HTML error pages returned with a 200 status are not usable images, even if the URL ends in .jpg.

  3. 3. Fetch without cookies or JavaScript

    The page HTML and image must be public to the crawler. A browser session can hide an access problem because it already has cookies, client-side code or a completed challenge.

When more than one image is useful

Add a second Open Graph image only when it has a real purpose, such as a square fallback. Declare each new og:image root before its own width, height, type and alt properties. Do not interleave structured properties from two candidates.

A Pinterest-oriented portrait image usually belongs in supported structured data rather than before the main wide Open Graph image. That keeps ordinary link cards stable while giving Pinterest another candidate where the page type supports it.

If the image changes, publish a versioned filename such as page-v4.jpg. Version the asset that changed instead of adding random parameters to the page URL; platform caches can treat page metadata and image bytes separately.

Check before publishing

  • The first image is the broadest safe candidate, not a logo or tiny thumbnail.
  • The image URL is absolute, public and stable.
  • Declared width, height and MIME type match the downloaded file.
  • The image has useful alternative text.
  • The page and image work for a fresh request without browser state.
  • Platform notes are treated as recommendations, not proof of failure.
Check a public URL

Primary reference

The Open Graph protocol documents image structured properties, repeated values and first-tag preference.

Reviewed July 14, 2026.