Open Graph Image Size: The 2026 Reference
One image size that works across Facebook, LinkedIn, X (Twitter), Slack, Discord, WhatsApp, and most other platforms that read Open Graph tags. Plus the meta tags you actually need, the file-size limits each platform enforces, and how to verify previews before they ship.
Want to audit the images on your live site?
Run a free scan →Looking for general (non-OG) image sizes? See our full image size reference.
Quick Answer
1200×630 pixels. One image satisfies Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage, and most of the long tail. Twitter/X officially recommends 1200×628 — a difference no human eye can detect, so the same file works there too.
Save it as JPG at quality 80–85. Aim for a file size under 300 KB. Set the URL via the standard <meta property="og:image"> tag. That covers 95 percent of cases.
Per-Platform Requirements
Most platforms read the same Open Graph tags but have slightly different rendering preferences. Here is how each major destination handles your og:image:
| Platform | Recommended Size | File Size Limit | Notes |
|---|---|---|---|
| 1200×630 | 8 MB | Min 200×200 or no card renders | |
| 1200×627 | 5 MB | 1200×630 works fine | |
| X / Twitter | 1200×628 | 5 MB | Set twitter:card to summary_large_image |
| Slack | 1200×630 | 5 MB | Reads og:image directly |
| Discord | 1200×630 | 8 MB | Reads og:image directly |
| 1200×630 | 300 KB target | Min 300×200; large files can be skipped | |
| iMessage | 1200×630 | ~5 MB | Standard OG; falls back gracefully |
| 1000×1500 (vertical) | 10 MB | Uses og:image only as fallback — Rich Pins prefer page-specific tags |
Pinterest is the outlier. It reads og:image but renders best with vertical (2:3 ratio) pinnable images at 1000×1500. If Pinterest is a meaningful traffic source for you, ship a separate vertical asset and reference it via Pinterest's Rich Pin tags rather than relying on og:image.
The Tags You Need
Minimum viable set for solid previews across every platform:
<meta property="og:title" content="Your page title"> <meta property="og:description" content="One sentence about the page."> <meta property="og:image" content="https://example.com/og-image.jpg"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="630"> <meta property="og:image:alt" content="Plain-language description of the image"> <meta property="og:url" content="https://example.com/page-url"> <meta property="og:type" content="website"> <meta name="twitter:card" content="summary_large_image">
Notice twitter:image is intentionally absent. When it's missing, X falls back to og:image — which is usually what you want. Add twitter:image only if you genuinely need different creative on X versus everywhere else.
File Format and Compression
Use JPG. WebP and AVIF are smaller, but social-platform scrapers don't universally support them yet — Facebook handles WebP, LinkedIn historically did not, and edge cases lurk. JPG is the path of least resistance and the file-size difference between a quality-80 JPG and a WebP at the same visual quality is rarely more than 30–40 KB. Not worth the platform-compatibility risk for OG images specifically.
PNG is fine if your image is graphic-heavy (sharp edges, flat colors, transparent elements rendered against the platform's background). For photographs or screenshots, PNG balloons file size 5–10× without a visible quality benefit.
Curious whether your live site's images are correctly sized?
Scan a URL →Common Mistakes
- No og:image at all. Without it, Facebook scrapes whatever raster image happens to load first on the page — usually a tiny logo or a generic stock shot. Your share preview becomes meaningless. Always set an explicit og:image.
- Image under 200×200. Facebook silently ignores small images and falls back to its generic-link rendering. The card looks broken even though technically your tags are valid.
- og:image URL returns 404 or requires authentication. Social scrapers don't carry user cookies. The image must be publicly accessible at the exact URL you list, served over HTTPS.
- One static og:image for every page. Better than nothing, but page-specific og:image dramatically improves click-through. Generate per-post images automatically — most modern frameworks (Next.js, Astro, Hugo) ship with built-in OG image generators.
- Forgetting og:image:alt. Required for accessibility, used by screen readers when shared previews appear in social feeds. Empty alt is a missed accessibility win.
- Aggressively caching the wrong image. Facebook caches scraped og:images for weeks. If you fix a bad og:image and it still shows the old preview, use the Sharing Debugger to force a re-scrape — don't assume the new image is actually live.
- 5+ MB images. Some platforms accept it, some quietly drop the preview, all of them slow down to scrape. Keep it under 1 MB and ideally under 300 KB.
Testing Tools
Test before shipping. Each major platform exposes a debugger that lets you scrape and preview your og:image as the platform itself sees it:
- Facebook Sharing Debugger — paste a URL, see exactly how Facebook will render the share card. Click "Scrape Again" to refresh after a change.
- LinkedIn Post Inspector — equivalent for LinkedIn. Useful because LinkedIn caches very aggressively.
- X (Twitter) validates inline now — compose a draft tweet with the URL and check the preview before posting. The legacy Card Validator was sunset in 2023.
- OpenGraph.xyz — third-party tester that previews how your URL will render across multiple platforms in one view.
When OG Images Get Heavy
For most sites, OG images are a one-off concern: ship a 1200×630 JPG, set the tags, move on. Where it gets interesting is when you generate OG images dynamically per page (one per blog post, one per product), at which point compression and CDN delivery start to matter — both for the platforms scraping you and for your own bandwidth bill.
Two tools that help if you serve OG images at scale:
ShortPixel
For sites generating per-page OG images via WordPress, Shopify, or static-site generators, ShortPixel can compress them on the way out without changing your workflow. JPG quality 80 ShortPixel-compressed is typically smaller than JPG quality 80 unprocessed by 30–50 percent.
Try ShortPixelBunny.net
Image CDN with on-the-fly resizing. If you serve OG images via Bunny, scrapers hitting your URL get a fast, geographically-close response — meaningful when dozens of platforms scrape your share endpoint within seconds of a viral post. Also useful for serving the same source image at multiple OG sizes (1200×630, 1200×1200 for square, 1000×1500 for Pinterest) via URL parameters.
Visit Bunny.netFrequently Asked Questions
What is the best Open Graph image size?
1200×630 pixels at a 1.91:1 aspect ratio is the universal sweet spot. It satisfies Facebook, LinkedIn, Slack, and Discord exactly. Twitter/X recommends 1200×628 — a 2-pixel difference no human can see, so 1200×630 works there too. The same single image serves every major platform without per-platform variants.
What is the minimum size for an Open Graph image?
Facebook requires at least 200×200 pixels or it ignores your og:image entirely and falls back to scraping any image on the page (often whatever logo loads first). LinkedIn requires 1200×627 minimum to render the large card and silently downgrades to a tiny thumbnail at smaller sizes. Below 600×315, most platforms render an awkward small preview that hurts click-through.
What is the maximum file size for an Open Graph image?
Twitter/X caps at 5 MB. Facebook caps at 8 MB. LinkedIn caps at 5 MB. Practically, target under 1 MB — every platform will accept it, page-load performance stays reasonable, and CDN bandwidth costs stay sane. JPG quality 80 typically lands a 1200×630 image around 150–250 KB.
Do I need separate images for Twitter and Facebook?
No. Set og:image to your 1200×630 file. If you want Twitter to use the same image but with summary_large_image card behavior, set twitter:card to summary_large_image and let twitter:image fall back to og:image — Twitter respects og:image when twitter:image is absent. The only reason to set both is if you want platform-specific creative.
Why does my Open Graph image not update on Facebook after I change it?
Facebook aggressively caches og:image scrapes — sometimes for weeks. Use the Facebook Sharing Debugger (developers.facebook.com/tools/debug/) and click "Scrape Again" to force a refresh. LinkedIn has its own Post Inspector for the same purpose. Twitter/X re-scrapes automatically when a new tweet is composed.
What is the difference between og:image and twitter:image?
og:image is the Open Graph standard, used by Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage, and many others. twitter:image is X-specific. If both are present, X uses twitter:image; everyone else uses og:image. Most sites set only og:image and let X use it as a fallback — there is no benefit to setting both unless you want different images.
Do I need og:image:width and og:image:height tags?
Strongly recommended. Facebook uses them to render the share preview without a flash of unstyled content while it scrapes the image dimensions itself. Their absence is not fatal but produces a slower, sometimes broken first-paint of the preview card. Set both to match your actual image dimensions.
Related Guides
- Best image sizes for websites in 2026 — the full reference for every common image type, including OG.
- WordPress featured image size — featured images and og:images overlap at 1200×630, useful if you run on WordPress.
- Shopify image sizes — covers Shopify-specific OG image considerations alongside product images.
- Hero image size — your hero often doubles as the og:image; this covers the dimensions side.
- Find oversized images on your website — the audit workflow for catching images that are too big for their layout slot.
- Squarespace image sizes — Squarespace blog headers automatically become og:image; relevant if you're on SQS.
- Email header image size — the other off-site image channel where your social/marketing imagery shows up.
Last updated: