An og:image that looks perfect when you paste the URL into Facebook's sharing debugger can still show a tiny, distorted, or completely absent thumbnail when someone actually shares your link — because different social platforms have different image requirements, different caching behaviors, and different fallback logic when requirements aren't met
The previous articles on this site covered Open Graph basics, designing OG images for clicks, algorithm suppression of link sharing, why og:image fails on X/Twitter despite correct Open Graph, and the Open Graph cache problem. This article addresses OG image rendering failures — the specific technical reasons why images fail to render correctly even when they appear correctly configured, and how to diagnose each failure mode.
The og:image URL must be absolute, not relative
The single most common Open Graph image implementation error: using a relative URL.
<!-- Wrong -->
<meta property="og:image" content="/images/og-share.png">
<!-- Correct -->
<meta property="og:image" content="https://www.example.com/images/og-share.png">
Why this fails: social platform crawlers request the og:image URL directly. A relative URL has no meaning without a base URL context — the crawler needs the full absolute URL to fetch the image. Relative URLs aren't technically invalid in all HTML contexts, but they're invalid for og:image specifically.
Easy to miss: this works fine when viewed in a browser (the browser resolves relative URLs against the page's base URL), but fails when the image URL is extracted by a crawler and fetched independently.
Image size requirements across platforms
Each platform has minimum and recommended dimensions:
Facebook/Meta:
- Minimum: 200×200 px
- Recommended: 1200×630 px (1.91:1 ratio)
- Maximum file size: 8MB
- Below 600×315: shows as small inline image, not large card
X/Twitter:
- Summary card with large image: minimum 300×157 px, recommended 1200×628 px
- 2:1 ratio required for large image card
- Maximum 5MB
- Images under Twitter's minimum show as small thumbnails or not at all
LinkedIn:
- Recommended: 1200×627 px
- LinkedIn is more forgiving of size variations than Twitter
WhatsApp:
- Uses og:image; recommended 300×200 px minimum
- Very lenient compared to other platforms
The practical recommendation: use 1200×630 px as the standard OG image size — it meets or exceeds requirements for all major platforms and renders well across the range of card sizes platforms use.
The og:image:type and og:image:width/height tags
Beyond og:image itself, supplementary Open Graph tags improve rendering reliability:
og:image:type: declares the MIME type of the image (image/jpeg, image/png, image/gif, image/webp). Without this, the crawler must infer the type from the file extension or the HTTP Content-Type response — which can fail for images served with incorrect or missing Content-Type headers.
og:image:width and og:image:height: declares the image dimensions. Without these, some platforms may fetch and inspect the image to determine its dimensions before deciding how to render the card. Providing dimensions explicitly allows the platform to make the rendering decision without a separate image inspection request — which can improve speed and reduce failure modes.
<meta property="og:image" content="https://example.com/og/article-image.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
WebP and AVIF compatibility
Modern image formats (WebP, AVIF) may not be supported by all social platform crawlers. Despite WebP being widely supported in browsers, some social crawlers still use older rendering engines and may fail to process WebP og:images.
Safer approach for og:image: use JPEG or PNG. These have universal support across all crawlers and platforms. Save the modern format (WebP/AVIF) for the actual page images that browsers load; use JPEG for the og:image URL specifically.
If you must serve WebP/AVIF: some platforms explicitly state their support — Facebook supports WebP; X/Twitter historically had issues with WebP and may or may not support AVIF. When in doubt, JPEG is the universally safe choice.
CORS and image access restrictions
Social platform crawlers may fail to fetch images that have CORS restrictions or require authentication:
Images served with Access-Control-Allow-Origin headers that exclude the crawlers' origins may be blocked. OG images should be publicly accessible without authentication — they're meant to be social sharing previews, which necessarily means publicly visible.
Images behind a CDN that requires referrer validation may block crawlers if the crawlers don't send the expected referrer. CDN configurations that restrict access to known referrers can prevent social crawler access.
Testing with Facebook's Sharing Debugger makes the platform's crawler request the image directly, revealing access issues that aren't visible when testing from a browser (where CORS and referrer policies apply differently).
og:image for articles vs og:image for homepage
Different page types often need different OG image strategies:
Homepage: a branded, text-on-image card with company name/tagline — consistent, evergreen, works well for direct homepage shares.
Blog posts and articles: ideally unique per article, reflecting the specific content. A generic "site header" OG image on every article makes sharing look unprofessional — every article share shows the same image regardless of content.
Product pages: product photography as og:image, matching the page content. The product image on the page and the og:image should typically be the same or very similar.
Programmatic OG image generation — dynamically generating unique OG images for each article with the article's title, date, and author baked into an image — is a common pattern. Services like Vercel OG, Cloudinary's text overlays, and Puppeteer-based screenshot services enable this without manually creating images for each post.
How to use the Open Graph Generator on sadiqbd.com
- Generate complete Open Graph markup including og:image, og:image:type, og:image:width, og:image:height — the generator should include all four for reliable rendering
- Use the Facebook Sharing Debugger (developers.facebook.com/tools/debug) and Twitter Card Validator after implementation — these show exactly what the platforms' crawlers see, including fetch errors for og:image
- Always use absolute URLs in the generated markup — verify the og:image value begins with
https://, not/or../
Frequently Asked Questions
Can I use SVG as an og:image? Not reliably. SVG support in social platform crawlers is inconsistent — Facebook has historically not supported SVG og:images; X/Twitter's support is unreliable. SVG is a vector format that requires rendering rather than direct display, and many crawler environments don't have the full rendering capabilities of a browser. For og:image, always use a rasterized format (JPEG, PNG) at the appropriate pixel dimensions. If your original image is an SVG (a logo, an icon), convert it to JPEG/PNG at 1200×630 px for the og:image specifically.
Is the Open Graph Generator free? Yes — completely free, no sign-up required.
Try the Open Graph Generator free at sadiqbd.com — create complete Open Graph and Twitter Card meta tags for any page.
