og:image Dimensions: What Actually Happens at Every Size

Most guides to og:image dimensions stop at telling you the right number to use. That's useful, but it skips the more practical question: what actually breaks when the number is wrong? Dimensions problems rarely throw an error. They show up as a slightly blurry card, an image cropped in a way that cuts off a logo, or — in a smaller number of cases — a platform quietly declining to show any image at all. Understanding what happens at each size makes it a lot easier to diagnose a bad preview after the fact, not just avoid one going in.

Too small: upscaling and visible blur

The most common og:image dimensions mistake is using an image that's smaller than what the platform wants to display it at. Facebook and most other crawlers don't reject an undersized image outright — they scale it up to fill the card, and scaling a raster image up introduces blur because there's no additional pixel data to work with. An image at 400×210px stretched to fill a 1200×630px card slot doesn't just look smaller, it looks soft, and text baked into the image (a headline, a logo wordmark) is usually the first thing that becomes visibly fuzzy, because fine edges are exactly what upscaling destroys.

There's a rough floor below which platforms stop trying. Facebook's documentation has historically cited 200×200px as an absolute minimum before an image is ignored, but 'technically accepted' and 'looks acceptable' are very different bars. Anything under roughly 600×315px is a visible quality problem in practice, even if the platform renders it without an error.

Too large: slow fetches and skipped images

Going oversized causes a different failure. Crawlers fetch og:image over HTTP with their own timeout budget, and a multi-megabyte image takes measurably longer to pull down than a well-compressed one at the same visual dimensions. Most platforms cap accepted file size somewhere between 5MB and 8MB depending on the crawler, but the practical problem shows up well before that ceiling: a slow fetch increases the odds that a crawler times out and falls back to showing no image, rather than waiting. This is a size-in-bytes issue more than a pixel-dimension issue, but the two are closely linked — a huge canvas with an uncompressed background photo is exactly the kind of file that trips this.

Wrong aspect ratio: unpredictable cropping

Dimensions being correct in total pixel count doesn't help if the aspect ratio is off. A 1200×1200px square image submitted where a platform expects roughly 1.91:1 gets cropped, not letterboxed — most crawlers crop to fit their card shape rather than adding padding. That means the platform, not you, decides what gets cut off, and it's rarely a considerate crop. A logo centered in a square source image can end up shoved to one edge or split in half once it's force-fit into a wide card. This is the dimensions failure that's hardest to spot in testing, because the image looks completely correct when you view it directly — the problem only appears inside the actual card chrome on the actual platform.

• 1.91:1 (1200×630px) is the safe default aspect ratio for the widest platform compatibility
• 1:1 (1200×1200px) works for platforms that prefer square, but crops badly if submitted where a wide card is expected
• Mixed-ratio source images (a screenshot, a random photo) are the most common cause of unexpected cropping — always export at the target ratio, don't submit and hope
• Test the actual rendered card, not just the raw image file, since cropping happens at render time, not upload time

Right pixel size, wrong resolution assumption

A less obvious failure: an image that's exactly 1200×630px but was designed at a lower effective resolution — upscaled from a smaller source before export, or built with a design tool set to a different DPI than assumed. The file reports the correct dimensions, so it passes any dimension check, but it visually reads as soft in the same way an undersized image does. This is common when a screenshot gets dropped straight into an OG image template without resizing consideration; the screenshot's native resolution rarely lines up cleanly with the template canvas, and stretching it to fit reproduces the exact upscaling blur described above, just hidden behind a technically-correct dimension metadata field.

Platform-specific size handling

Not every platform treats an out-of-range image the same way. Facebook is relatively forgiving — it scales and crops rather than rejecting outright, which is exactly why undersized-and-blurry is such a common failure rather than undersized-and-missing. LinkedIn tends to be stricter about what it will fetch and render reliably, and a marginal image that Facebook happily scales up can end up simply not appearing on LinkedIn at all. Slack and Discord crop tightly into a compact card, which makes wrong-aspect-ratio problems more visually obvious there than on a full-width Facebook card, since there's less canvas to hide an off-center crop in.

Diagnosing which failure you're looking at

When a shared link looks wrong, the visual symptom usually points to the cause. A soft, low-detail image almost always means undersized-and-upscaled. A crop that cuts off content at the top, bottom, or one side almost always means wrong aspect ratio. A missing image entirely — no card at all — is more often a file-size timeout or a broken URL than a dimensions problem specifically, though an extremely undersized image can also trigger a platform's fallback-to-nothing behavior. Checking the actual served image's pixel dimensions and file size, not just what you intended to export, is the fastest way to confirm which of these is happening.

Compression artifacts that mimic a dimensions problem

One more failure worth distinguishing from a pure dimensions issue: heavy JPEG compression applied to hit a smaller file size can produce visible blocking artifacts around text and sharp edges, which looks similar to upscaling blur but has a different cause and a different fix. Upscaling blur comes from too few source pixels being stretched across too much canvas; compression artifacts come from a correctly sized image being compressed too aggressively after the fact. The fix for the first is a larger source image; the fix for the second is a less aggressive compression setting, or switching from JPEG to PNG for text-heavy images, where compression artifacts are most visually obvious. Confusing the two leads to re-exporting at a larger size when the actual problem was compression quality, which doesn't fix anything.

Retina and high-density displays

A less commonly discussed dimensions issue: 1200×630px is a comfortable size on a standard display, but on a high-density (retina-class) screen, an image rendered at exactly that pixel count can look noticeably softer than one exported at double the resolution and scaled down by the platform. This doesn't mean you need to hit an exact 2x target for every platform — most crawlers handle scaling reasonably well — but it does mean that when an image already looks borderline soft at 1200×630px in testing, exporting from a higher-resolution source and letting the platform downscale often produces a visibly sharper result than trying to sharpen the same file after the fact.

Getting dimensions right without re-litigating them per page

The dimensions failures above are almost all human error at export time — a screenshot dropped in at the wrong size, a designer forgetting the safe aspect ratio, a background image compressed inconsistently from one page to the next. useopengraph's templates fix the canvas size, aspect ratio, and safe margins once per template, so every rendered image comes out at the correct dimensions and reasonable file size automatically, regardless of who's generating it or how often. Because renders are served from versioned URLs under /api/render/{templateId}/v{version}/..., a dimensions or layout fix applied to the template shows up correctly on the next version without hunting down every individually-exported file across the site.