The Correct OG Image Size in 2026 (Updated for Every Major Platform)

If you're checking whether the correct og image size for 2026 has changed from what you remember, the short answer is no — 1200×630px is still the standard, and it's been stable for long enough that it's worth treating as settled rather than something to re-verify every year. What's more useful than re-confirming the headline number is a quick pass through what's actually changed at the margins: file size ceilings, format support, and a couple of platform-specific quirks that do shift more often than the core dimension.

The 2026 baseline: still 1200×630px

1200×630px, a 1.91:1 aspect ratio, remains the size that works across the broadest set of platforms with the least fuss. It's not that alternative sizes fail everywhere — it's that this specific ratio is the intersection of what Facebook, X, LinkedIn, Slack, and Discord all render cleanly without cropping into something unintended. If you're setting up a new OG image pipeline in 2026 and want one size that requires no per-platform special-casing, 1200×630px is still the answer, unchanged from prior years.

The one addition worth keeping in your back pocket, not as a replacement but as a secondary option, is a 1200×1200px square variant. It's relevant for platforms or in-app browsers that render square previews, and a handful of messaging surfaces still default to cropping wide images down to square if no square version is offered. For most sites this remains optional — worth having if you're already generating multiple sizes, not worth the extra maintenance if you're not.

Quick-reference table

• Facebook: 1200×630px (1.91:1), don't go below 600×315px or the image gets upscaled and looks soft
• X (Twitter): 1200×630px for a summary_large_image card — requires twitter:card meta tag set explicitly, or it can fall back to a small thumbnail regardless of image size
• LinkedIn: 1200×630px, and stricter than most about requiring an absolute, publicly reachable image URL rather than a relative path
• Slack: 1200×630px works, but Slack's card is more tightly cropped than Facebook's — keep text and logos closer to center
• Discord: 1200×630px, renders slightly larger in embeds than Slack but follows the same aspect ratio expectations
• iMessage: uses og:image the same way, generally forgiving on exact size but benefits from the same 1200×630px default

What's actually changed in file handling

The pixel dimension has stayed flat, but file-size and format tolerances are where platforms have moved over time, and it's the part worth re-checking periodically rather than assuming from memory. Most crawlers now accept files up to somewhere in the 5MB to 8MB range, though staying well under that ceiling remains the safer practice — a large file slows the crawler's fetch and increases the odds it times out before rendering anything at all. WebP support has broadened across most modern crawlers, but it's still not universal enough to treat as a safe default over PNG or JPEG if broad compatibility matters more than shaving a few kilobytes off file size.

Where sites actually get the 2026 numbers wrong

The correct dimensions haven't been the hard part for a while — the number is easy to look up. What actually goes wrong in practice, even now, is inconsistency: a site that got its OG image right on the homepage two years ago but never applied the same sizing discipline to blog posts, product pages, or landing pages added since. Templates change, contributors change, and without a system tying every new page's image back to the same canvas size, individual pages drift out of spec one at a time until an audit turns up a handful of pages serving images at the wrong ratio or an outdated fallback asset nobody re-checked.

The other place 2026-specific confusion shows up is people assuming a platform update changed sizing requirements when what actually changed was something else entirely — a crawler timeout threshold, a caching behavior, or a stricter check on absolute URLs. It's worth separating 'the image looks wrong when shared' from 'the dimensions are wrong,' because the two are frequently unrelated, and troubleshooting the wrong one wastes time re-exporting an image that was never the problem.

Why the standard has stayed stable this long

It's worth understanding why 1200×630px hasn't moved, because it explains why re-checking it every year is largely unnecessary going forward. The size isn't an arbitrary platform preference that could change with a redesign — it's a practical compromise between three constraints that haven't shifted: it needs to be large enough to look sharp on high-density displays, small enough to keep file sizes and fetch times reasonable, and a ratio wide enough to hold a headline without feeling cramped, while still cropping acceptably to the tighter card shapes some platforms use. Those three constraints are about display technology and network behavior, not platform branding, which is why the number has outlasted several rounds of individual platform redesigns without needing to change.

That stability is also why chasing 'is this still current' as an annual question is usually wasted effort. The parts of this space that do move — file size ceilings, format support, individual platform crawler behavior — are worth revisiting periodically, but they don't require re-deriving the core dimension from scratch. Treat 1200×630px as a fixed constant you can build tooling around with confidence, and spend the recurring-check effort on the parts that actually vary instead.

Checking your current images against the standard

If you haven't audited og:image sizing across your site recently, the fastest check isn't opening every page's source — it's using a debugger that shows what a platform's crawler actually parses right now for a given URL, since that surfaces both the dimension and any fetch problems in one pass. Doing that across a handful of representative pages (homepage, a blog post, a product page if you have one) will usually surface whether size drift is a real issue on your site or a non-issue you can stop worrying about for another year.

What would actually signal a real change worth reacting to

Because the core dimension has stayed flat for years, it's worth knowing what would actually count as a signal worth reacting to versus routine platform noise. A genuine change would be a platform publicly announcing a new preferred aspect ratio for link cards, or a crawler starting to reject images at the current standard size — either would show up in a platform's own developer documentation, not as a rumor or a single anecdotal broken share. A single link rendering oddly on one platform is far more likely to be a caching issue, a malformed tag, or an unrelated fetch failure than evidence the underlying size standard changed. Treating every individual broken preview as a possible dimensions update is a good way to waste time chasing a non-issue instead of checking the more likely, more mundane cause.

The more useful habit for 2026 and beyond isn't re-verifying the pixel dimension periodically — it's keeping a way to check any individual URL's actual live rendering on demand, so that when something does look wrong, you can tell within a minute whether it's a dimensions problem, a caching problem, or something else entirely, rather than guessing and re-exporting an image that was never the issue.

How useopengraph keeps this current without manual re-checks

useopengraph's templates fix the canvas at 1200×630px (or whatever ratio you choose) once, and every page using that template renders at the correct size automatically going forward — there's no per-page re-export to keep in sync with a standard that, as covered above, mostly hasn't moved. Renders are served from versioned URLs under /api/render/{templateId}/v{version}/..., so a template correction rolls forward to new versions without disturbing pages that already shipped. And the Cache Debugger lets you check exactly what Facebook, X, LinkedIn, and other platforms are parsing for a live URL right now, which is the fastest way to confirm the correct size is actually what's showing up in the wild rather than trusting that it should be.