Open Graph Image Size: What Each App Documents

Open Graph Image Size: What Each App Documents

Make your Open Graph image 1200 x 630 pixels, a PNG or JPEG well under 5 MB, and point to it with an absolute https URL in og:image plus og:image:width, og:image:height and og:image:alt. That size meets Meta's recommendation for high-resolution displays, sits inside X's limits for its large-image card, and works in Slack and Discord.

The size is only half of a working preview. Most "og image not showing" reports trace back to something other than pixels: a relative URL, a tag added by JavaScript that a crawler never runs, a preview cached for days under the old image URL, or an SVG file that X explicitly refuses and the other major consumers do not list. Each platform publishes a different slice of the rules. Meta and X give pixel figures, Discord gives formats and time limits, and Slack gives no image figures at all.

What each platform's own documentation says

The Open Graph protocol is a vocabulary, not an image spec. Every number below comes from the consumer that reads the tags, and "not documented" means the official page we read on November 13, 2026 does not state that value. It does not mean there is no limit.

A few things in that table deserve a closer look.

Meta's two floors do different jobs. The 200 x 200 figure is the hard minimum: below it the image is not allowed. The 600 x 315 figure is the threshold for the large layout. Meta says an image smaller than 600 x 315 "will still display in the link page post, but the size will be much smaller." So an image between the two floors does not fail; it shrinks into a small thumbnail, which is easy to mistake for a broken preview.

X's maximum is generous and its ratio is not 1.91. The large-image card supports images up to 4096 x 4096 pixels under 5 MB, and X describes the card's aspect ratio as 2:1. X's troubleshooting guide separately gives 144 x 144 pixels as a minimum for card images in general. That is lower than the large card's own 300 x 157 floor, so for the large card the 300 x 157 figure is the one to design against.

Slack publishes how it fetches, not what it accepts. Its robot documentation says it looks for oEmbed and Twitter Card or Open Graph tags, and that if the tags point to media "we will fetch that file as well to check validity and extract other metadata." No pixel, ratio or byte figure appears there. Any Slack size chart you see elsewhere is somebody's observation.

Discord documents more than people expect. Its link preview page lists six image formats, says the whole fetch must finish within 10 seconds, allows at most 5 redirects, and caps the data returned at 50 MB. It does not give a ratio.

Google Discover is a different reader with a different ratio. Google says that specifying a large, representative image with schema.org markup or the og:image tag "can influence which image is chosen as the thumbnail in Discover," and that Discover's large images should be at least 1200 px wide, more than 300,000 total pixels and 16x9. Google also tells you to avoid generic images such as a site logo in og:image. That is unrelated to the favicon Google shows next to a search result, which has its own rules in our favicon sizes and formats guide.

LinkedIn is the gap in this update. LinkedIn's help pages could not be read for this check. Our social media design guide recorded LinkedIn Help's specification for images on page posts with a URL on October 22, 2026: 1200 x 627 pixels at 1.91:1, more than 200 px wide, PNG or JPEG, up to 3 MB. Those values were not re-verified on November 13. If LinkedIn is your main channel, read the current page before you lock a template, and treat the 3 MB figure as the tightest byte limit on this list until you have.

The 1.91:1 arithmetic

The number 1.91 is a rounded ratio, and 1200 x 630 does not hit it exactly. Divide and see:

At 1200 pixels wide, an exact 1.91:1 image would be 1200 / 1.91 = 628.27 pixels tall. Round that and you get 628. Meta's own 1200 x 630 comes out about 0.27 percent narrower than 1.91, and LinkedIn's 627 about 0.2 percent wider. Meta says to keep images "as close to 1.91:1 aspect ratio as possible to display the full image in Feed without any cropping," and two pixels either way is as close as whole pixels allow. You can pick 630, 628 or 627 without a visible difference. Pick one and use it everywhere, so your template, your exported files and your og:image:height tag agree.

Two other checks fall out of the table:

• 1200 x 630 clears Google Discover's pixel test by a wide margin. It is 756,000 pixels against a floor of more than 300,000, and it is exactly 1200 wide, which meets the "at least 1200 px wide" line. The ratio does not match Discover's 16x9; more on that in the crop section.
• Halving keeps the ratio. 600 x 315 is 1200 x 630 at half scale, which is why it sits right at Meta's large-display floor. If you ever generate images on the fly and need a fallback size, halve the recommended one rather than inventing a new ratio.

Why 1200 rather than 600? Meta says the 1200 x 630 recommendation is "for the best display on high resolution devices." A preview card on a phone is often drawn at a few hundred CSS pixels wide, but a phone screen packs two or three device pixels into each CSS pixel. The relationship between those units is covered in our DPI and PPI guide; the short version is that a 600-pixel image drawn 400 CSS pixels wide on a 3x screen has to be enlarged, and it looks soft.

A safe zone that survives every crop

Here is the problem a single image has to solve. Meta wants about 1.91:1. X's large card is 2:1. Google Discover's large thumbnails are 16x9, which is 1.78:1. None of these platforms says how it will fit an image that does not match, whether by cropping, scaling or padding, and none says where a crop would fall. The safe answer is to design the 1200 x 630 canvas so that anything important sits inside every plausible frame.

Take the two frames that differ most from 1.91:1 and assume each is cut from the centre:

• A 2:1 frame at 1200 wide is 1200 x 600. From a 630-tall image that removes 30 rows, 15 at the top and 15 at the bottom.
• A 16:9 frame at 630 tall is 630 x 16 / 9 = 1120 wide. From a 1200-wide image that removes 80 columns, 40 on each side.

The area inside both is 1120 x 600, running from x 40 to x 1160 and from y 15 to y 615. Then add a margin of your own, because a preview that puts a headline 2 pixels from the card edge looks cramped even if nothing is cut. We used 60 more pixels at each side and 60 more at top and bottom, which leaves a text and logo area of 1000 x 480 pixels from x 100 to x 1100 and y 75 to y 555.

How to use that box when you build the template:

1. Backgrounds run to every edge. Colour, photography and pattern fill the full 1200 x 630, so a crop never exposes a blank strip.
2. Words, logos and faces stay inside 1000 x 480. The 15-pixel and 40-pixel losses then never touch anything that carries meaning.
3. Do not put a border right on the canvas edge. A thin frame drawn at the outside edge is the first thing a 2:1 or 16:9 cut breaks, and a border that is visible on two sides and missing on two others looks like an error.
4. Check the small version. Meta draws images under 600 x 315 much smaller, and Discord shows a small image beside the text unless you set twitter:card to summary_large_image. A headline that reads at full size can be illegible as a thumbnail.

How large should text be? None of the platforms says how wide it draws the card, so there is no documented number to design against. You can still reason about it with stated inputs. Suppose a card is drawn 500 CSS pixels wide. That is a scale of 500 / 1200 = 0.417, so a 48-pixel headline in your template shows at about 20 CSS pixels and a 24-pixel caption at 10. At 350 pixels wide, the scale is 0.292 and the same 48-pixel headline lands near 14. Those widths are illustrations, not measurements of any app, but they explain why short headlines set large work better than a paragraph of small type. The pillar guide's section on type for phone screens goes further on minimum sizes.

The safe-zone idea is not new to anyone who has set up a print file; our print bleed and safe area guide uses the same reasoning with trim lines instead of crop frames. The difference online is that nobody publishes where the trim falls, so the margins have to be wider than strictly necessary.

The tags that make the image appear

The Open Graph protocol lists four required properties: og:title, og:type, og:image and og:url. It defines og:image as "An image URL which should represent your object within the graph," and then gives the image its own structured properties. A complete head for one page looks like this:

<meta property="og:title" content="Open Graph Image Size" />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://example.com/og-guide/" />
<meta property="og:image" content="https://example.com/og/og-guide-v2.png" />
<meta property="og:image:type" content="image/png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Diagram of a 1200 by 630 card with its safe zone" />
<meta name="twitter:card" content="summary_large_image" />

Every line has a reason, and most of them come from a consumer's documentation rather than the protocol itself.

Use an absolute https URL

The protocol calls og:image "An image URL." It does not say whether a relative path is allowed, and neither Meta's webmaster page nor X's markup page describes resolving one. Every example on ogp.me and Meta's pages uses a full URL. Meta describes og:image:secure_url as an "https:// URL for the image," and the protocol says secure_url is "An alternate url to use if the webpage requires HTTPS." If you write the og:image value as a complete https URL in the first place, you never depend on undocumented behaviour, and you rarely need secure_url at all.

Two related mistakes are common in static sites:

• The image path is correct on your local build and wrong in production. A site generator that writes og:image from a site URL variable will happily emit http://localhost:3000/og.png if that variable is not set at build time. Check the built HTML, not the template.
• The image URL redirects. Discord follows at most 5 redirects and must finish the whole fetch, including measuring images, within 10 seconds. A chain from http to https to www to a CDN path uses up that budget fast. Serve the image at its final address.

Give width and height

Meta says that og:image:width and og:image:height specify the image dimensions to the crawler so it can "render the image immediately without having to asynchronously download and process it." Without them, Meta's own documentation explains, "the first person who shares a piece of content won't see a rendered image." Discord says the same in its own terms: provide width and height, because "Without them, Discord fetches the image to measure it," and that measurement counts against its 10-second fetch limit.

The values must describe the real file. If your template says 1200 x 630 and the exported file is 2400 x 1260 for a sharper result, change the tags to match.

Write alt text for the image

The protocol is direct about this: "If the page specifies an og:image it should specify og:image:alt," and it defines the value as "A description of what is in the image (not a caption)." X's markup page maps twitter:image:alt to og:image:alt as its fallback and limits that alt text to a maximum of 420 characters. Write what the image shows, not the page title again. If the image is mostly text, the alt is that text. Our guide to decorative and informative alt text covers how to tell which kind of description an image needs.

Decide whether you need twitter: tags

X reads Open Graph tags as fallbacks. Its markup page maps twitter:title to og:title, twitter:description to og:description, twitter:image to og:image, twitter:image:alt to og:image:alt, and twitter:card to og:type. It also says that if og:type, og:title and og:description exist but twitter:card is absent, a summary card may be rendered. A summary card is the small layout. So the one X tag most sites need is:

<meta name="twitter:card" content="summary_large_image" />

That same tag changes Discord too. Discord's documentation says a title, description and one image with no layout tags produce "text with a small image," and that when twitter:card is summary_large_image "you'll see text with a large image below it." One line, two platforms.

Add a separate twitter:image only when you want X to show a different file, for example a 1200 x 600 version cut exactly to 2:1. Otherwise the og:image covers it.

When a page lists several images

The protocol says a tag with multiple values is written as multiple meta tags, and "The first tag (from top to bottom) is given preference during conflicts." Discord goes further: "Two or more og:image tags produce a gallery," showing at most 4 images. If your CMS adds a site-wide default og:image and then a page-specific one below it, the default comes first and may win. Emit one og:image per page unless you want a gallery, and put the one you want first.

Make the tags visible to a crawler that runs no scripts

Discord's documentation is the most explicit on this: it makes a single GET request for the shared URL, parses the HTML that comes back, and "No code is executed, so tags added by a client-side script after load are never seen." Slack says its robot fetches "as little of the page as it can (using HTTP Range headers)." Meta notes that its crawler only accepts gzip and deflate encodings. Put the Open Graph tags in the server-rendered or statically exported HTML, near the top of the head, and make sure your server can answer with one of those encodings or none.

Formats and file weight

The format choice is mostly decided by who refuses what.

SVG is the trap. It is a good format for a hero illustration on the page itself, and this site uses SVG heroes for exactly that reason. But X states plainly that "SVG is not supported," Discord's format list does not include it, and Meta's list of og:image:type values does not either. Export a raster copy for the og:image. Our image formats guide explains why PNG suits flat graphics and JPEG suits photographs, and that reasoning applies unchanged here.

How big will the file be? The limits are 8 MB at Meta and under 5 MB at X, but a 1200 x 630 card rarely gets near either. To show the range, we generated two 1200 x 630 test images with Python's Pillow library (version 12.3.0) on November 13, 2026 and measured the files:

The flat card is 12.8 times smaller as PNG than as JPEG. The noisy image is 4.7 times smaller as JPEG than as PNG. Random noise compresses worse than most real photographs, so treat the noisy rows as a pessimistic case. Even then, the largest file measured is about 1.1 MB, well under 5 MB. If your og:image is approaching a megabyte, it is probably a photograph saved as PNG, or a file exported at several times the size the tags declare.

File weight matters for a second reason. Discord's 10-second limit covers the whole fetch, image measurement included, so a heavy image on a slow server can drop out of the preview even though it is under every stated byte cap. The same thinking about bytes and time that applies to a page's main image, covered in our hero image file size and LCP guide, applies here at a smaller scale.

When the og:image does not show: symptom to cause

Start from what you see. Each row names a cause that one of the platforms documents, so you can tell a real limit from a guess.

Two items in that table catch even careful sites.

robots.txt works differently per crawler. X's troubleshooting guide lists a robots.txt file blocking Twitter from your card metadata as a cause of failure and tells you to allow its crawler. Slack says the opposite about itself: "We do not currently honor robots.txt files." So a robots rule written to block one bot will not tell you anything about the others. If you block crawlers by name, and many sites now block AI training bots, check that the rule does not also catch the bots that build link previews. The user agents to look for in your logs are Slackbot-LinkExpanding for Slack, facebookexternalhit for Meta (the string Meta gives for testing) and Twitterbot for X.

Caching keys on the image URL, not the file. Meta says: "We cache all images referenced based on each image's URL," so if you replace an image you should "Use a new URL for the new image or the image won't be updated." X says images in a card "are also cached based on URL." Overwriting og.png with a new design and expecting previews to change is the single most common reason a correct fix appears not to work. Version the filename (og-guide-v2.png) or add a query string, and update the tag.

Refreshing a preview on each platform

Even with versioned URLs, each platform caches the page's tags for a different length of time and offers a different way to ask for a fresh read.

Meta adds one instruction that is easy to miss: "Don't remove old images, as there maybe existing stories that reference the old image." When you version an og:image, leave the old file on the server. Deleting it does not update old shares; it breaks them.

The X advice about query parameters deserves a caution. Adding ?test=1 to a page URL creates a new address as far as X's cache is concerned, which is the point, but Meta asks that og:url be the canonical, "undecorated URL, without session variables, user identifying parameters, or counters." Use the parameter only for testing. The og:url tag on the page should still name the clean address.

A checker you can run on your own HTML

Preview tools show what one platform thinks of your page. A small script can check the rules from all the documents above at once, before you deploy. This one reads an HTML file, collects the meta tags, and reports problems. It is a sketch for static output, not a full HTML parser; it expects each meta tag's attribute name before its content, as most generators write them.

// Usage: node og-check.mjs page.html
import { readFileSync } from "node:fs";
const html = readFileSync(process.argv[2], "utf8");
const tags = {};
for (const m of html.matchAll(/<meta\s+(?:property|name)="([^"]+)"\s+content="([^"]*)"/g)) {
  (tags[m[1]] ??= []).push(m[2]);
}
const first = (k) => tags[k]?.[0];
const problems = [];
for (const k of ["og:title", "og:type", "og:image", "og:url"]) {
  if (!first(k)) problems.push(`missing ${k}`);
}
const img = first("og:image");
if (img && !/^https:\/\//.test(img)) problems.push(`og:image is not an absolute https URL: ${img}`);
if (img && /\.svg(\?|$)/i.test(img)) problems.push("og:image is SVG (X, Discord and Meta's type list do not include it)");
const w = Number(first("og:image:width")), h = Number(first("og:image:height"));
if (!w || !h) problems.push("missing og:image:width or og:image:height");
else {
  if (w < 1200) problems.push(`width ${w} is under Meta's 1200 px recommendation`);
  const r = w / h;
  if (Math.abs(r - 1.91) / 1.91 > 0.01) problems.push(`ratio ${r.toFixed(3)} is more than 1% from 1.91`);
}
if (!first("og:image:alt")) problems.push("missing og:image:alt");
if (!first("twitter:card")) problems.push("no twitter:card (X may fall back to a summary card, not a large image)");
console.log(problems.length ? problems.join("\n") : "ok");

We ran it on November 13, 2026 with Node.js 22 against two files. The first was the nine-line head shown earlier in this article. The output was a single line:

ok

The second was a typical broken head: og:title and og:url present, og:type missing, og:image set to the relative path /og/og-guide.svg, width and height both 800, no alt and no twitter:card. The output was:

missing og:type
og:image is not an absolute https URL: /og/og-guide.svg
og:image is SVG (X, Discord and Meta's type list do not include it)
width 800 is under Meta's 1200 px recommendation
ratio 1.000 is more than 1% from 1.91
missing og:image:alt
no twitter:card (X may fall back to a summary card, not a large image)

Seven problems from five lines of markup, and every one of them maps to a row in the troubleshooting table. The 1 percent ratio tolerance is our choice for this script, not a platform rule; it accepts 1200 x 627, 628 and 630 and rejects a square. If you design separate 2:1 files for X, run the check against og:image only and leave twitter:image out of it.

What the script cannot tell you: whether the image URL actually responds, how many redirects it takes, how long the fetch lasts, or what the file's real pixel size is. For those, request the image URL directly and compare its dimensions to the tags. A width tag that disagrees with the file is worse than no tag, because Meta and Discord will both use the declared size to lay out the card.

Building it into a template

The arithmetic and the rules reduce to a short production spec. For one og:image per page that has to work across all the consumers above:

• Canvas: 1200 x 630 pixels. If your design tool works at 2x, export 2400 x 1260 and change both dimension tags to match; X's 4096-pixel ceiling and both byte limits leave room.
• Text area: keep words, logos and faces inside 1000 x 480, starting at x 100 and y 75.
• Format: PNG for flat or text-heavy designs, JPEG for photographs. No SVG.
• Weight: aim for well under 1 MB. That keeps you below every documented byte limit, including LinkedIn's 3 MB figure from October, and inside Discord's time budget.
• File name: include a version, and change it whenever the design changes. Keep old versions on the server.
• Tags: og:title, og:type, og:url, og:image as an absolute https URL, og:image:type, og:image:width, og:image:height, og:image:alt, and twitter:card set to summary_large_image.
• Content: something representative of the page. Google tells Discover publishers to avoid a generic site logo as og:image, and a logo-only card tells a reader in a chat thread nothing about the link.

That last point is where design matters more than spec. A link preview competes with the message around it. The design side of social graphics, from type size on phones to keeping one master file for several placements, is in the social media design guide. Those placements belong to the networks; the og:image is the one that belongs to your website, and it travels with every link anyone shares.

Open Graph Image Questions

What is the best Open Graph image size?

1200 x 630 pixels. It meets Meta's recommendation for high-resolution displays, is within X's 300 x 157 to 4096 x 4096 range for the large card, and is exactly 1200 wide for Google Discover. Keep important content inside a central 1000 x 480 area so 2:1 and 16:9 frames do not cut it.

Is og:image 1200 x 630 or 1200 x 628?

Either. An exact 1.91:1 ratio at 1200 wide is 628.27 pixels tall, so 628 is the nearest whole number and 630 is Meta's own figure. The difference is under 0.3 percent. Pick one, export at that size, and set og:image:height to match the file.

Why is my og:image not showing on Facebook?

The most common causes are a missing og:image:width and og:image:height on a brand-new page (the first share then has no image), an image under 200 x 200 pixels or over 8 MB, or an old image cached under the same URL. Run the URL through Meta's Sharing Debugger and publish changed images at new URLs.

Can I use an SVG as my og:image?

No. X says SVG is not supported for its cards, Discord's list of supported formats does not include it, and Meta's og:image:type values are JPEG, GIF and PNG. Keep the SVG for the page and export a PNG or JPEG copy for og:image.

Do I need twitter:image if I already have og:image?

No. X falls back to og:image when twitter:image is missing. You do need twitter:card set to summary_large_image if you want the large card on X, and the same tag gives you the large layout on Discord.

How do I make Slack or Discord show my new preview image?

Both cache previews for about 30 minutes. Discord suggests resharing the link with a new query string such as ?v=2. Slack documents no refresh tool, so wait out the cache or test with a fresh URL. In both cases, publish the new image at a new file name so the image cache cannot serve the old one.

Should og:image be a relative or absolute URL?

Absolute, with https. The Open Graph protocol only calls it "an image URL," none of the platform pages read for this guide documents resolving a relative path, and every official example uses a full URL.

Sources

• The Open Graph protocol, https://ogp.me/: four required properties, og:image definition, structured properties url, secure_url, type, width, height and alt, arrays with first tag preferred, the og:image:alt recommendation; no size, ratio or file-size requirement stated. Checked November 13, 2026.
• Meta for Developers, images in link shares, https://developers.facebook.com/docs/sharing/webmasters/images/: 200 x 200 minimum, 600 x 315 large-display threshold, 1200 x 630 recommendation, 1.91:1, 8 MB, gzip and deflate, first-share behaviour, pre-caching with width and height, Sharing Debugger and Graph API, caching by image URL, keeping old images. Checked November 13, 2026.
• Meta for Developers, sharing for webmasters, https://developers.facebook.com/docs/sharing/webmasters/: basic tags, og:url as undecorated canonical URL, og:image:type values JPEG, GIF and PNG, secure_url as https URL, facebookexternalhit user agent, debugger triggers a scrape, caching by URL. Checked November 13, 2026.
• X Developer Platform, summary card with large image, https://developer.x.com/en/docs/x-for-websites/cards/overview/summary-card-with-large-image: 2:1, 300 x 157 minimum, 4096 x 4096 maximum, under 5 MB, JPG, PNG, WEBP and GIF, SVG not supported, alt text up to 420 characters. Checked November 13, 2026.
• X Developer Platform, cards markup, https://developer.x.com/cards/markup: Open Graph fallbacks for title, description, image, image alt and card type; summary card when twitter:card is absent. Checked November 13, 2026.
• X Developer Platform, troubleshooting cards, https://developer.x.com/en/docs/x-for-websites/cards/guides/troubleshooting-cards: re-indexing roughly every seven days, testing with URL parameters, images cached by URL, public accessibility, downloads up to 5 MB, 144 x 144 minimum, robots.txt blocking. Checked November 13, 2026.
• Slack API documentation, Slackbot robot page, https://api.slack.com/robots: oEmbed, Twitter Card and Open Graph tags, fetching linked media, Slackbot-LinkExpanding user agent, HTTP Range requests, about 30 minutes of caching, robots.txt not honoured. Checked November 13, 2026.
• Discord Developer Documentation, "Link Previews", https://docs.discord.com/developers/link-previews/overview: single GET with no script execution, image formats, width and height, gallery of up to 4 images, summary_large_image layout, about 30 minutes of caching and the ?v=2 reshare, 5 redirects, 50 MB, 10 seconds. Checked November 13, 2026.
• Google Search Central, Google Discover documentation (last updated March 9, 2026), https://developers.google.com/search/docs/appearance/google-discover: images at least 1200 px wide, more than 300,000 total pixels, 16x9, max-image-preview:large, og:image or schema.org can influence the thumbnail, avoid generic logos. Checked November 13, 2026.
• LinkedIn Help, Page image specifications, https://www.linkedin.com/help/linkedin/answer/a563309: figures as recorded in our social media design guide on October 22, 2026; not re-read for this article.

The ratio table, crop frames, safe-zone box, text-scale examples, file-size measurements and checker output are this desk's own arithmetic and tests, run on November 13, 2026.