Open graph image size: one file that clears every surface
Open graph image size has one answer that satisfies every surface at once: 1200 x 630 pixels, JPG or PNG, under 5 MB. One file clears Meta's recommended dimensions and X's card limits, and works as the fallback for both.
Open graph image size has one answer that satisfies every surface at once: 1200 × 630 pixels, JPG or PNG, under 5 MB. That single file clears Meta's recommended dimensions, sits at the 1.91:1 ratio it asks for, stays under both documented file-size ceilings, and works as the fallback for X's card. You do not need a set. You need one image and four lines of markup.
Before this page
This chapter assumes the four required Open Graph properties are already on your pages. If you are not sure they are, the count across 26 real homepages is in open graph tags on 26 homepages, and it includes the specification's own list of what counts as required.
Why one file works and a set does not
Every surface that renders a link preview reads the same two families of tags, in the same order, and each one crops the result to its own frame. The image you supply is an input to somebody else's layout. That is the whole reason a single generous file beats a folder of per-platform variants: you cannot control the crop, so you control the source.
The Open Graph protocol makes og:image one of the four required properties, describing it as "An image URL which should represent your object within the graph". It also defines the optional structured properties around it: "og:image:width - The number of pixels wide. og:image:height - The number of pixels high. og:image:alt - A description of what is in the image (not a caption)." And if you supply several: "If a tag can have multiple values, just put multiple versions of the same meta tag on your page. The first tag (from top to bottom) is given preference during conflicts."
The image is your file. The crop belongs to whoever is rendering it. Size for the crop you cannot see.
The numbers, and where each one comes from
Two published sources set the constraints, and they do not conflict — the binding limits are simply the tighter of the two.
| Constraint | Value | Source |
|---|---|---|
| Recommended size | at least 1200 × 630 | Meta sharing docs |
| Minimum size | 200 × 200 | Meta sharing docs |
| Aspect ratio | as close to 1.91:1 | Meta sharing docs |
| Max file size | 8 MB | Meta sharing docs |
| Max file size | under 5 MB | X card reference |
| Formats | JPG, PNG, WEBP, GIF | X card reference |
| SVG | not supported | X card reference |
Meta's own wording on the first row is "Use images that are at least 1200 x 630 pixels for the best display on high resolution devices", with "The minimum allowed image dimension is 200 x 200 pixels" and "Try to keep your images as close to 1.91:1 aspect ratio as possible to display the full image in Feed without any cropping". X's card markup reference states its side: "Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported."
So the safe intersection is 1200 × 630, JPG or PNG, under 5 MB. That is the number to hand to whoever makes the file.
The markup to paste
Four lines do the required work; the fifth and sixth save a round trip and describe the picture. Absolute URLs only — a root-relative path is the single most common way this breaks.
<meta property="og:image" content="https://example.com/og/home.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A one-line description of the picture">
<meta name="twitter:card" content="summary_large_image">Note the attributes. Open Graph values go on property; X's card values go on name. Both families are widely parsed either way, and in our 26-homepage crawl on 2026-08-27, three sites wrote at least one of them on the wrong attribute — including MDN, which writes all ten of its og: tags on name.
How to check it in three commands
Run these against a live URL. Each one ends in something you can compare against the table above.
- Read what the page declares:
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ | grep -o '<meta[^>]*og:image[^>]*>'. If nothing comes back, the tag is being injected by script and most consumers will never see it. - Confirm the URL is absolute and reachable: copy the content value and run
curl -sI <url> | head -3. You want a 200 and an image content type. A 404 here renders as no image and no error. - Confirm the real pixel size matches what you declared. On macOS,
sips -g pixelWidth -g pixelHeight file.jpg. Declaring 1200 × 630 on an 800 × 600 file is worse than declaring nothing, because a consumer may lay out for a size it never receives.
Three ways an open graph image size goes wrong
All three are visible in the markup or in one HTTP request, so none of them needs a rendered preview to find.
- A relative path in
og:image. The protocol expects a URL. In the 26-homepage crawl, one site declared bothog:imageandtwitter:imageas/dev-cdn/v/marketing/…. A consumer that does not resolve against the page URL gets nothing at all, and your own browser will never show you the problem. - A logo instead of a banner. A square file in a 1.91:1 frame is either letterboxed or centre-cropped. In the same crawl, of the seven sites that declared dimensions, four declared something smaller than 1200 × 630 — 400 × 400, 512 × 512, 800 × 600 and 1024 × 1024.
- Text baked into the image. Whatever you write in there is cropped by frames you cannot see, and it is invisible to anything reading text. Put the words in
og:title, where they are already being read.
Where this stops helping
Getting the size right does not get the preview refreshed. Every surface caches what it fetched the first time, and none of them re-reads on your schedule. If you change the file, change the URL as well; a new path is the only cache-busting mechanism that works the same way everywhere.
The second boundary is measurement. We have not verified a rendered preview on any surface, because doing that honestly means posting a real link on each one, and the validators that used to answer the question are behind a login. Everything here comes from published requirements and from what 26 homepages actually declare. If a specific platform crops your image in a way this page does not predict, the platform is right and this page is incomplete.
Common questions
What is the correct open graph image size?
1200 × 630 pixels, which is Meta's recommended minimum for high-resolution displays and sits at the 1.91:1 ratio it asks for. Keep the file under 5 MB so it also clears X's limit, and use JPG or PNG so it clears every format list.
Do I need a separate image for X?
No. X's card reference documents og:image as the fallback for twitter:image, so one file covers both. Supply a second one only when the two are genuinely meant to differ — and remember that you now have two files to keep in sync.
Why is my link preview showing no image?
In order of how often we see it: the URL is relative, the URL returns a non-200, the tag is inserted by script and was not in the delivered HTML, or the file is an SVG. X states plainly that SVG is not supported.
Should I declare og:image:width and og:image:height?
They are optional and they help, because a consumer that knows the dimensions can lay out the card before the image arrives. Declare them only if they are true. In our crawl only seven of 26 homepages declared them at all.
Does og:image:alt matter?
It is the accessible description of the card image, and almost nobody writes one — three of 26 in our crawl. It costs one line. For what those 26 homepages ship on the X side of the same markup, see twitter card tags on 26 homepages, and to see what an engine receives from your page before any of it is parsed, see how QueryWin works.
Part of the QueryWin handbook · Level 2
