One image at 1200 by 630 pixels, in PNG or JPEG, under about 1 MB, with the important content inside the middle 1080 by 600. That file meets the published specs from Meta and LinkedIn, which is the whole answer to the Open Graph image size question for almost every site.
The dimensions are the easy part. They are not usually what breaks, either. What breaks is text sitting too close to an edge that one platform crops, an image that never updates because a crawler cached the old one months ago, or a card that renders with no picture at all because the file was 4 MB on a slow origin. The OG image size question is really three questions, and only one of them is about pixels. This guide covers the spec, the safe zone, the caching behaviour that makes people think their tags are wrong, and how previews resolve when the thing being shared is a short link. If your preview is missing entirely rather than badly cropped, link preview not showing is the diagnosis guide.
The Size, and Why It Is That Size
The 1.91:1 ratio shows up in both Meta's and LinkedIn's documentation. The Open Graph protocol itself (accessed 2026-10-25) sets no size; its examples are 400x300 and 300x300, and it asks for og:image:alt whenever you specify an image. A de-facto standard formed around the platforms' numbers.
| Platform | Documented guidance (accessed 2026-10-25) |
|---|---|
| Meta (Facebook) | Recommends 1200x630, about 1.91:1. Large card from 600x315. Minimum 200x200. Maximum 8 MB. |
| 1.91:1, minimum 1200x627, maximum 5 MB. Images narrower than 401 px show as small thumbnails. Square and vertical images may be cropped. | |
| X | Developer docs returned HTTP 402 and 404 for us, so no numbers here. |
| Slack, Discord, WhatsApp, iMessage | No official size documentation checked. We make no claim. |
The sources are Meta's image guidance and LinkedIn's link preview help page. X documents its cards separately, but we couldn't load that documentation, so check it before you rely on a size for X.
The Safe Zone Nobody Mentions
A card is rarely shown at the ratio you designed it in. LinkedIn's own page says square and vertical images may be cropped, and anything under 401 px wide becomes a small thumbnail. The 1080 by 600 zone below is our rule of thumb, not a platform number.
Keep anything that must survive inside the middle 1080 by 600, centred, and treat the outer band as decoration you can afford to lose. In practice that means the headline sits centre-left rather than hard against the edge, the logo lives inside the margin rather than in the corner, and there is no thin border, because a border is the one design element that looks broken the instant it gets cropped.
Contrast matters too. Cards sit on light backgrounds in some clients and dark in others, so an image that relies on its surroundings for separation can lose its edges.
The Tags Around the Image
Four tags do the work. Two of them are the ones people skip.
<meta property="og:image" content="https://example.com/og/spring-launch.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta
property="og:image:alt"
content="Spring launch: 30 percent off through May"
/>
<meta name="twitter:card" content="summary_large_image" />
Use an absolute URL with scheme and host, since a crawler reads the tag with no page context. Meta says width and height let its crawler render the image on the first share without fetching it first. And og:image:alt is the accessibility tag that costs nothing and is missing almost everywhere.
Why Your New Image Will Not Show
This is the one that generates support tickets. You fixed the image, you can see the new file at its URL, and the card still shows last quarter's design.
Meta's docs say its crawler caches images by URL, and that changing the image doesn't update previews of existing shares. Three ways out, in the order I'd try them:
- Force a re-scrape with Facebook's Sharing Debugger. LinkedIn has a Post Inspector too, though the help page we read doesn't describe its caching.
- Publish the image at a new filename, which is a different URL with no cache entry. Meta recommends this, and it's the reliable one.
- Change the shared URL itself, which is trivially easy when what you are sharing is a short link you control rather than a permanent page address.
Before you publish, the free Open Graph checker fetches a URL and shows the title, description, image, site name and a Twitter card preview it finds. It reads tags only. It doesn't report image dimensions or clear any platform's cache.
Previews When You Share a Short Link
A short link has no Open Graph tags of its own and does not need any. Elido's edge answers crawlers with the ordinary redirect, because link previews in chat apps need to follow it, and it doesn't count those fetches as clicks (the bot filter is a user-agent list, so some scripted fetches can slip through). The card is built from the destination's tags. If it's wrong, fix the destination.
Two things do depend on the link layer. A server-side redirect is the safe choice, one more reason to keep the chain short. And repointing a short link changes its preview, though platforms that cached the old card keep showing it.
One gap: Elido has no per-link OG image or title override, so a short link can't carry a different card than its destination. Microsite pages do have an OG image field. If you need per-link cards, tell us; it's on our backlog.
To get the link and the click data in one place, start a workspace on your own domain and check the card before the send.
A Checklist Worth Keeping
- 1200 by 630, PNG or JPEG, absolute HTTPS URL, under 1 MB by our habit. That is the whole OG image size decision.
- Nothing that matters outside the middle 1080 by 600 (our rule of thumb), no thin borders.
og:image:width,og:image:height, andog:image:altpresent.twitter:cardset tosummary_large_imageif you want the big card on X.- New image, new filename, then re-scrape before announcing anything.
Get those five right once, template them into your page head, and Open Graph images stop being a thing you think about. Which is the correct amount of attention to give them.
Read the Cornerstone Series
This post sits in the tutorials cluster. For previews that fail outright rather than crop badly, link preview not showing is the platform-by-platform fix, and how to make a clickable link covers the layer underneath.
Related on the Blog
- Link preview not showing? Causes and how to fix it
- Shorten a link for X (Twitter): what t.co does to it
- How to track social media links: clicks by channel
- What is a branded link, and why it converts better
- How to redirect a URL: six ways, and when each is right
- Custom domain short links: DNS, TLS, and the edge
Frequently asked questions
What is the best Open Graph image size?
1200 by 630 pixels, an aspect ratio of 1.91:1, as PNG or JPEG. Meta recommends exactly that size and LinkedIn asks for 1.91:1 at 1200x627 or larger (both pages checked 2026-10-25), so one file satisfies both. Meta's stated minimum for a large card is 600x315, and below 200x200 it won't show. We keep files under 1 MB as our own rule of thumb.
Why is my og:image not updating?
Because the platform cached the old one. Meta documents that its crawler caches images by URL and that a changed image needs a new URL, or a re-scrape through the Sharing Debugger. Changing the image does not update previews of shares that already exist. Publishing at a new filename is the reliable route.
How big can an og:image file be?
The documented ceilings are 8 MB at Meta and 5 MB at LinkedIn (checked 2026-10-25). We aim for under 1 MB, which is our own habit rather than a platform rule, because a heavy file on a slow origin is a likely reason for a card with no image. X's developer docs would not load for us, so we state no X limit.
Do I need a separate image for X and LinkedIn?
Usually not for Facebook and LinkedIn, since 1200x630 meets both documented specs. For X we could not load the developer docs on 2026-10-25, so check its card documentation for the tags and limits it currently asks for. Either way, one image and one URL means fewer things to forget when the page changes.
Where does the preview image come from when I share a short link?
From the destination page, not from the link. Elido answers crawlers with the normal redirect, so the platform reads the tags on the page it lands on. A short link inherits its destination's preview, and Elido has no per-link image override today. A missing card after shortening usually points to the target page's tags.
Does the image need an absolute URL?
Use one. A full URL with scheme and host is the safe choice, since a crawler reads the tag without page context. Serve it over HTTPS. Setting og:image:width and og:image:height lets Meta's crawler render the image on the first share without downloading it first, per its docs.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
No signup needed. Sign up free for 50 links a month.