Open Graph image sizes for every platform

Start with a versatile landscape master

A 1200 by 630 pixel image is a widely used Open Graph starting point, but it is not a guarantee of identical rendering everywhere. Confirm each platform’s current recommended dimensions and file constraints before publishing.

Keep essential content inside a safe area

Place the headline and logo away from the outer edges so a preview crop does not remove them. Avoid putting critical meaning in small decorative details or at the very top and bottom of the canvas.

Check social and messaging previews

X, LinkedIn, Facebook, Slack, Discord, Telegram, and WhatsApp may show different crops or image treatments. Test actual shared URLs where possible rather than assuming a source image will be displayed in full.

Use the right metadata and cache checks

Set page-level Open Graph title, description, and image values that match the destination page. After changing an image, use the platform’s current preview or refresh workflow to check whether a cached version is still being shown.

Keep the file accessible

Use a stable public URL, a supported format, and a sensible file size. Make sure crawlers can fetch the image and that the page metadata points to the intended absolute URL.

A useful export and validation checklist

Keep the source image at a high enough resolution for the largest target preview, export a compressed web-friendly file, and check its actual dimensions and file size. Use an absolute, publicly reachable URL in the page metadata.

Validate with each platform’s current sharing inspector or a real test post. Confirm title, description, image, and crop as a set; the platform may cache old metadata after deployment.

Do not assume messaging apps use identical metadata

Some chat clients use Open Graph tags, while others may apply their own fetch behavior, crop, or cache. Test the actual link in the messaging apps that matter to your audience.

When a preview is missing, check crawler access, robots rules, TLS and redirect behavior, and whether the image URL can be fetched without a session cookie.

Use a test matrix for sharing surfaces

For every important channel, record the target URL, card type, image URL, observed crop, and last checked date. Test one page with a long title and one with a short title so line wrapping does not surprise you after launch.

If a channel needs a special crop, generate a separate image only for that surface. Keep a shared master where it works, but do not sacrifice readability to force every preview into one composition.

Optimize the image response

Serve the image directly over HTTPS with a stable response, correct content type, and no login requirement. Avoid redirects that require cookies or lead to an HTML error page instead of an image.

After changing metadata or the asset, verify the live response and the rendered preview. A correct local file does not prove that a crawler can retrieve it from production.

Common mistakes that break previews

A preview can fail when the image URL requires authentication, the server returns HTML instead of an image, or the page points to a file that was moved. It can also look broken when important text sits in an area cropped by the destination.

Check response status, content type, dimensions, and public accessibility from the deployed site. Then inspect the rendered card because a technically valid image can still be framed poorly.

Build a small set of reusable templates

Create a branded master with flexible title space and a few variants for article, product, or campaign pages. Keep the visual system consistent but let the subject change so two shared links do not look like the same page.

Store the source design and output URL next to page metadata. That makes it easier to correct a stale or misassigned image without rebuilding the card from memory.

How to debug a missing image preview

Start with the exact production URL being shared. Check that the page returns successfully, the `og:image` value is absolute, and the image request returns an image with a supported content type without cookies or a login redirect.

Then inspect robots rules, TLS, redirects, file dimensions, and cache state. If the page HTML is rendered dynamically, verify the tags in the response a crawler receives rather than relying on client-side markup after JavaScript runs.

Choose a shared master or platform-specific exports

A 1200 × 630 master is a practical starting point for many Open Graph previews. Keep core information centered so a crop still works, then create a separate composition only if a priority platform consistently removes something important.

Do not put the same headline, logo, and interface into every card by default. Page-specific imagery helps readers distinguish an article, product page, and campaign when several links appear in the same conversation.