OG Images: The Size Is the Easy Part

The size is 1200 × 630 pixels. That is the practical default and it renders cleanly nearly everywhere.

Now the useful part, because if you are reading this it is probably not because you wanted a number. It is because you pasted a link somewhere and got a bare URL with no image, and you have already checked that your image is the right size.

First, a small correction

The Open Graph protocol does not specify 1200 × 630, or any size. It defines the tags — og:image, and optional structured properties like og:image:width, og:image:height, og:image:type and og:image:alt. Each platform decides how to render the card.

1200 × 630 is the overlap of what the major platforms want, which is why everyone recommends it. It is a convention, not a rule, and knowing that helps when a platform crops your image differently from another.

The tags

<meta property="og:title" content="Page title">
<meta property="og:description" content="One or two sentences">
<meta property="og:url" content="https://example.com/page">
<meta property="og:type" content="website">
<meta property="og:image" content="https://example.com/og-image.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Describes what the image shows">
<meta name="twitter:card" content="summary_large_image">

Two things in there that people leave out and then wonder about.

Width and height. Without them, the very first time a link is shared the card can render blank while the platform goes off to fetch and measure your image. Two tags avoid it.

twitter:card. X does not fall back to Open Graph for the card type. Omit this and you get a small square thumbnail instead of the large image you designed.

Why your preview is not showing

In rough order of how often each one is the answer.

Your tags are injected by JavaScript. This is the big one for single-page apps. Social scrapers fetch your HTML and do not run JavaScript, so tags added by React, Vue or a client-side helper are invisible to them. The tags must be in the server-rendered HTML. View source — actual source, not the inspector, which shows the page after JavaScript has run. If the og:image tag is not in there, that is your answer.

The platform cached an old scrape. Facebook and LinkedIn hold onto what they found the first time, sometimes for a long time. Fixing your tags changes nothing until you force a re-scrape. Use the Meta Sharing Debugger and the LinkedIn Post Inspector — both show the preview as the crawler sees it and both let you clear the cache for a URL.

The image URL is relative. /og-image.png works in your browser and means nothing to a crawler on another machine. It must be an absolute HTTPS URL.

The crawler cannot reach it. Staging sites behind basic auth, images on a protected path, or a robots.txt that disallows the crawler. The image has to be publicly fetchable with no login.

The image is too small or the file too large. Very small images get rejected outright, and platforms have file size caps. Keeping it at 1200 × 630 and a sensible file size avoids both — run it through the compressor if your export is heavy.

You are testing in the wrong place. Some chat apps generate previews differently from social platforms, and a few cache per-conversation. Test on the platform that actually matters to you before assuming it is broken everywhere.

Test before you ship anything that matters

Never post a link you care about without previewing it first. A launch announcement with a broken card is not something you can quietly fix — the cached version follows the post around.

The debuggers worth bookmarking are the Meta Sharing Debugger, the LinkedIn Post Inspector, and any general Open Graph checker that shows several platforms at once. Paste the live URL, look at what comes back, and force a re-scrape after each change.

Designing one that works

The technical side is the easy half. Most OG images fail because of how they look, not how they are configured.

It will be seen small. In a feed on a phone, your 1200 pixel image is rendered a few hundred pixels wide. Text that looks reasonable in your design tool becomes unreadable. Use far fewer words and far larger type than feels right.

Keep everything important away from the edges. Platforms crop to different aspect ratios — some are close to 1.91:1, X's large card is nearer 2:1, and compact previews crop harder still. Design as if the outer edges might disappear, and keep your title and logo in the middle.

Contrast matters more than polish. The card sits against a white or dark feed background among other cards. A subtle, low-contrast design disappears; a bold one does not.

Say something specific. A generic brand image on every page is a missed opportunity. Page-specific cards — the article title rendered into the image — get noticeably more attention, which is why so many sites generate them per page.

If you are starting from a screenshot or an existing graphic, size it to 1200 × 630 with the resizer first, then compress. Do not let a platform scale a mismatched aspect ratio for you, because it will crop somewhere you did not choose.

Generating them per page

Once you have more than a handful of pages, making these by hand stops being practical. Most modern frameworks can render an image per page at build time or on request, usually from a template with the title and a background.

That is worth setting up if you publish regularly. It turns the OG image from a one-off asset into something every page gets for free, and page-specific cards consistently perform better than one generic image repeated everywhere.

The short version

1200 × 630, absolute HTTPS URL, include width, height and alt, and add twitter:card because X will not infer it. If the preview is not showing, check whether your tags are in the server-rendered HTML before anything else, then clear the platform's cache. And design for a thumbnail on a phone, not for the canvas you are looking at.