AI SEO

OG image size: the numbers, and what actually matters

6 min readUpdated Sep 2026
Every guide answers this question with the same pair of digits, and most of them are copying each other rather than checking. The digits are fine. What they leave out is that the number is a moving convention, and that two smaller decisions, the ratio and the declaration, do more work than the number itself.

The working size, with its date

As checked on 2026-09-01, the working size for an og:image is 1200 by 630 pixels, an aspect ratio of roughly 1.91:1.

The date is part of the answer. Platform requirements change without notice and without ceremony, which is why this page carries one number with a date instead of a table of many without one; a figure nobody re-checks is a rumour with formatting. If you are reading this long after that date, treat the digits as a starting point and the method below as the answer.

Of the two halves, the ratio matters more than the pixel count. A sharper image at the same proportions ages well as screens improve; an image at the wrong proportions loses its edges today, at every resolution, for the reason the composition page explains: platforms scale a matching shape and cut a mismatched one.

What other sizes actually get

Nothing errors when the size is wrong, which is the trouble.

An oversized image is scaled down and survives. An image at a different ratio is cropped toward the slot it lands in, edges first, and whatever lived near those edges, a logo in the corner, the end of a headline, simply leaves the frame. A small image is the worst case: platforms that consider it too small fall back to a plain link, and the page previews as if it had declared nothing at all.

None of this is visible from your own browser, because your page does not render its own card. It shows up where links are pasted, which is also where it is cheapest to check.

Declaring the size beside the address

Open Graph has companion properties for the purpose:

<meta property="og:image" content="https://example.com/social/card.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

The pair does not change what the image is. It tells a platform what the image is before the file arrives, and the practical effect is on the first share: a consumer that knows the dimensions can lay the card out immediately instead of fetching, measuring and reflowing. The Open Graph page places these two among the tags worth carrying; here it is enough that they should agree with the file. A declaration that contradicts the actual pixels is worse than none, because there is no rule for which side a reader believes.

Minimums, weights, and how to check them

Every platform sets a floor below which an image is ignored and a weight above which it is refused, and this page will not print those figures, because they are the ones that move most and are checked least.

The method is worth more. The platforms that read og:image publish their own card documentation and their own preview tools; the figure that matters is the one in those documents on the day you ship, for the platforms your audience actually uses. A practical floor holds without any table: an image already at 1200 by 630 clears the documented minimums of the major platforms by a wide margin, which is one more argument for the working size over a clever small one.

The file behind the number

Size is settled at the moment of export, and two habits keep it settled. Export the card as its own file at exactly the working size, instead of pointing og:image at whatever hero image the page already uses: page images are sized for the page, and the crop that follows is the one described above. And keep the address stable, because platforms cache fetched cards; a renamed file forces every earlier share to re-resolve, while a replaced file at the same address updates on their schedule, not yours. Neither habit needs a figure, and both outlive whichever figure is current.

One file for every platform

Mostly yes, and the exception has its own vocabulary.

A single 1200 by 630 file serves the platforms that read Open Graph, which is most of them. The separate case is the one described under Twitter and X cards: a second vocabulary with its own frames, where the shape you request changes how the same image is presented. A page that declares both vocabularies can still point them at one file; what it cannot do is make one file look right in a frame built for a different shape, so check the two previews separately.

Where a page declares no image at all, a card can be composed at exactly the working size, which is one reason the composed cards need no size decisions from anybody.

FAQ

What size should an og:image be?

1200 by 630 pixels, at roughly 1.91:1, as checked on 2026-09-01. The ratio is the half worth protecting: it decides whether platforms scale your image or cut it. If you are far from that date, verify the figure against the platform documentation before shipping anything expensive.

Can one image serve every platform?

Usually. The Open Graph readers share the same expectations closely enough for one 1200 by 630 file to serve them all. The Twitter and X card vocabulary frames images its own way, so a page declaring both should be previewed in both places, even when a single file stands behind the two declarations.

What happens if my image is smaller than a platform's minimum?

The platform ignores it, and the link previews as though no image was declared: a bare card, or whatever the consumer scrapes on its own. Nothing warns you. Shipping at the working size clears documented minimums with room to spare, which is cheaper than tracking every floor separately.

Do og:image:width and og:image:height have to match the file?

Yes, or they should be absent. The declaration exists so a consumer can lay out the card before fetching the file; when the two disagree, different readers resolve the conflict differently, and the result is the kind of inconsistency nobody can debug from the page itself.

Does image size affect where the page ranks?

There is no evidence that it does, and nobody credible has claimed a ranking effect on the record. The size decides how the link looks when a person shares it, which influences whether people click a share. That is an effect on readers, not on rankings, and it is the honest reason to get the size right.

AI SEO, without the overclaiming

These pages pin down what enrichment fills and what it never touches. The platform they describe is Bridge CDN, where an account is created.