What size should an Open Graph image be

1200 × 630 pixels. That’s the answer for essentially every case, it’s roughly 1.91:1, and it’s what the large-format card on most platforms is laid out for. Keep the file under about a megabyte, use PNG or JPEG, and serve it over HTTPS at an absolute URL.

The rest of this is why that shape, and what actually happens when you deviate.

Why 1200 × 630

Two things at once: an aspect ratio and enough resolution.

The ratio is what card layouts are designed around. Feed a platform something noticeably taller or squarer and it crops to fit — usually centre-cropped, sometimes top-cropped, and never in a way you chose. A 1:1 image in a 1.91:1 slot loses about half its width or gets letterboxed with padding.

The resolution matters because cards render at various sizes on various screens, and a 600-pixel-wide image on a high-density display looks soft. 1200 wide is comfortably above what any card needs, which means downscaling rather than upscaling. Going much larger buys nothing and costs file size.

What breaks at other sizes

Too small. Below roughly 600 × 315, some platforms decline to use a large card at all and fall back to a small thumbnail — or to no image. This is a common cause of “my image is there but the card is tiny”.

Wrong ratio. Cropping, and you don’t control where. Text near the edges of a square image disappears in a wide slot.

Very large files. A crawler fetching your image has a timeout. A multi-megabyte PNG on a slow origin can simply fail to download, leaving a card with no picture and no error message anywhere you’d see it.

Very large dimensions. Some platforms impose a maximum and reject images beyond it. 4000 pixels wide is not safer than 1200; it’s a bigger download with the same result at best.

Formats

PNG for anything with text, flat colour or a logo. Crisp edges, larger files.

JPEG for photographs. Much smaller at equivalent quality, with artefacts around sharp text — which is why PNG wins for the typical text-over-background preview image.

WebP is well supported by browsers and less reliably supported by link-preview crawlers. Not worth the risk for a file whose entire job is to be fetched by those crawlers.

Animated GIF shows as a static frame. If you use one, make sure the first frame is the frame you want.

SVG does not work. Don’t.

Absolute URLs, always

<!-- works -->
<meta property="og:image" content="https://example.com/images/preview.png">

<!-- frequently doesn't -->
<meta property="og:image" content="/images/preview.png">

A relative path requires the crawler to resolve it against the page URL. Many do. Enough don’t that a relative og:image is one of the most common reasons a preview has no image while everything looks correct in your source.

Same for the scheme: serve the image over HTTPS. An HTTP image referenced from an HTTPS page is sometimes fetched and sometimes not.

Design for the small render

The mistake that survives every dimension check: designing a preview image at full size, on a large monitor, and never looking at it small.

A card in a phone-width feed renders that 1200-pixel image at perhaps 350 pixels wide — under a third of the size you designed it at. Consequences:

Text must be large. As a rule, if a line of text is thinner than about 1/20th of the image height, it won’t be readable on a phone. That’s much bigger than it feels while designing.

Keep a safe margin. Different platforms crop slightly differently, and some round the corners. Keeping content 5% or so away from every edge means nothing important gets clipped.

Contrast over subtlety. Light grey text on white is legible at full size and invisible at card size.

Three or four words, not a sentence. The card already has a title and a description as real text. The image doesn’t need to repeat them.

Declare the dimensions

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

This lets a platform reserve the right-shaped space before the image has downloaded. Without it, the first person to share a URL sometimes sees a card with no image — the crawler hadn’t finished fetching when it rendered — which then caches, and now everyone sees it.

Cheap tags, and they prevent a problem that’s annoying to diagnose.

When you change the image

Changing the file at the same URL usually does nothing visible, because platforms cache their own copy of the image, keyed by URL. Two options:

Use a new URL. preview-v2.png, or a query string. The most reliable approach, and it works everywhere without asking anyone’s permission.

Ask the platform to re-fetch, using its own debug tooling. Works, one URL at a time, per platform.

The versioned-filename habit is the one that saves time. Treat preview images as immutable: to change one, publish a new file.

The checklist

1200 × 630, PNG for text and JPEG for photos, under a megabyte, absolute HTTPS URL, width and height declared, large type with a 5% margin, and a new filename whenever the design changes. That covers essentially every link-preview image problem worth having a rule about.