OG Image Size Guide: 1200x630 and Beyond

Getting your OG image size right is critical. Wrong dimensions mean cropped images, blurry previews, or worse — no image at all when your link is shared. The good news: one size works almost everywhere, and the exceptions are easy to handle once you know them.

The Standard: 1200 x 630 Pixels

1200×630 is the universally recommended OG image size. It satisfies every major platform's requirements while looking crisp on high-DPI displays — at 2x retina rendering, 1200px wide gives you a sharp 600pt display with room to spare. Anything smaller and you're gambling on the platform's upscaling, which almost always adds softness.

One thing most size guides skip: the ratio matters more than the absolute pixels. 1200×630 keeps you at 1.91:1, the ratio every platform uses for landscape cards. If you design at a different ratio, platforms will crop rather than letterbox, and that crop is almost never where you want it.

What Real Sites' OG Images Look Like (Measured)

Guides hand out 1200×630 like a law, so I went and checked what big sites actually serve. I grabbed the live og:image files from three well-known homepages today, downloaded each one, and parsed the real dimensions out of the file headers. The results don't match the mythology:

Three observations. Only Wikipedia even declares dimensions, and its declaration is wrong — the page says 1200×1200 while the server hands out a 300×300 file. The scrapers don't verify: they take the declared numbers on faith and render the card anyway. GitHub serves the textbook 1200×630 but weighs 604 KB — nearly double the 300 KB ceiling most of us recommend — and it still scrapes fine on a fast connection. YouTube's 1200×1200 file is just 7 KB, proof of how far a simple image can be compressed. The real risk isn't the declared size: it's the byte weight and fetch speed. A bloated PNG on a slow CDN fails where GitHub's 604 KB survives.

That measurement runs on our own pages too — the ogimgen generator exports strict 1200×630 files, and the homepage declares matching og:image:width and og:image:height tags, so the meta and the file always agree.

Platform-by-Platform Requirements

Two rows deserve extra attention. Discord's 32×32 minimum sounds forgiving, but its crawler also ignores images it can't fetch in under a few seconds — a slow CDN with a cold cache will silently produce no preview at all. And Twitter/X reads twitter:image before falling back to og:image, so if you only set og tags, X will still work but may render slightly differently than its card validator previews. One more floor worth knowing: Meta's crawler drops any image under 200×200 entirely, on Facebook and Instagram alike — the 600×315 figure in the table is Facebook's recommended minimum for card quality, not the crawler's kill-switch.

File Size and Format Matter

Dimensions get the attention, but file size kills more previews. Facebook and Discord both cap at 8 MB, and most CDNs will happily serve a 12 MB PNG — which then fails silently at share time. Keep OG images under 300 KB when possible. The measured sites back that up: GitHub's 604 KB scraped fine, YouTube's 7 KB flew, and anything past about 1 MB starts timing out on mobile networks. Weight beats pixels every time.

• PNG for text-heavy images with logos and flat colors — a text 1200×630 PNG should land under 300 KB
• JPEG for photos and gradients (quality 80-85 is usually invisible, around 200 KB)
• Avoid WebP in the og:image tag — support is inconsistent across platform scrapers

The Safe Zone: Where Platforms Actually Crop

Every platform crops differently, and the cut points are predictable. Facebook clips about 20% off each side on mobile. WhatsApp and Telegram render square-ish thumbnails on phones, trimming the left and right edges further. Discord doesn't crop at all — full rectangle. LinkedIn crops hard. So the layout rule is simple: treat the center 80% of your canvas — a 960×504 area centered in 1200×630 — as the only space you can trust. Anything closer than 120px to a side edge is at risk.

• Always include og:image:width and og:image:height that match the real file — without them Facebook re-scans the image before rendering, adding seconds of delay that reads as "broken"
• Put the title in the top-left and your logo in the bottom-right; that's where the eye goes and where platforms crop least
• Test with the Facebook Sharing Debugger before publishing, and again after any CDN or caching change
• If you change an image, force a re-scrape — platform caches hold old previews for days

Aspect Ratio and the Square Variant

The ideal aspect ratio is 1.91:1, and sticking to 1200×630 keeps you there. If you ever need a square variant — for chat apps that render 1:1 thumbnails on phones, or X's small summary card — generate a second 1080×1080 image and point the platform-specific tag at it: og:image stays 1200×630, twitter:image gets the square version.

The One-Paragraph Version

Export 1200×630 (1.91:1), keep the file under 300 KB, declare og:image:width and og:image:height that match what the server actually serves, and put everything important inside the center 960×504 safe zone. That one file covers Facebook, Instagram, X, LinkedIn, Discord, Slack, WhatsApp, and Telegram; add a 1080×1080 square only if chat thumbnails or X's small card matter to you. Don't trust the declared dimensions in other people's tags — I measured GitHub, YouTube, and Wikipedia today, and the served files told a different story than the tags suggested. If yours claim one size while the file is another, no crawler calls you out, but the crop you designed for may not be the crop you get. Check your own tags with the free OG checker, rebuild the image with ogimgen in about 30 seconds, and keep the file lean with the OG image file size guide.