OG Image Not Showing? 9 Reasons and How to Fix Each One

If your OG image is not showing when you paste a link into Facebook, X, LinkedIn, Slack, WhatsApp or iMessage, the cause is almost always one of a handful of things: the platform cached an old (or empty) preview, your og:image URL is relative or 404ing, the image is the wrong size or too large, the crawler is being blocked, or the tag is missing entirely. Run the link through a re-scrape after fixing the tag and the card usually returns within minutes.

Below are the nine reasons this happens, in rough order of how often they bite, with the exact check and fix for each.

1. The platform cached an old or empty preview

This is the single most common reason. Facebook, LinkedIn and X scrape a URL once and cache the result — sometimes for days. If they scraped your page before you added the image (or while it was briefly broken), they keep showing that stale, image-less card no matter how many times you re-paste the link.

The fix is to force a re-scrape:

• Facebook / Meta: Sharing Debugger → paste URL → Scrape Again.
• LinkedIn: Post Inspector → paste URL (it re-fetches automatically).
• X: there is no public card validator anymore — append a harmless query string (?v=2) to bust its cache, then post.

Before you assume anything is broken, always re-scrape once. A surprising number of “OG image not showing” reports are pure cache.

2. The image URL is relative, not absolute

Crawlers do not resolve relative paths the way a browser does. og:image must be a fully qualified, absolute URL:

<!-- Broken: crawler can't resolve this -->
<meta property="og:image" content="/images/card.png">

<!-- Correct -->
<meta property="og:image" content="https://example.com/images/card.png">

Protocol-relative URLs (//example.com/card.png) are also a gamble — some crawlers handle them, others do not. Always use the explicit https:// form.

3. The image returns a 404, 403, or redirect

The tag can be perfect while the file behind it is gone. Open the exact og:image URL in a private browser window. If it 404s, the path is wrong. If it 403s, your server or CDN is refusing the request — often because the crawler’s user-agent is blocked (see #6). And if the image URL redirects, many crawlers will not follow the hop and simply drop the image. Point og:image at the final, directly served file.

4. The image is the wrong size

The recommended Open Graph image size is 1200×630 pixels (a 1.91:1 ratio). Get too far from this and platforms either crop your card awkwardly or downgrade it to a tiny thumbnail.

• 1200×630 — the universal target for a full-width “large” card.
• Below 600×315 — most platforms refuse the big card and show a small square thumbnail instead, which reads like “no image.”
• Square or portrait images get center-cropped, so text near the edges disappears.

If you are not sure what dimensions your live image actually is, paste the URL into Ogwave’s free preview tool — it reports the real image size and flags it when it is not 1200×630.

5. The file is too large or an unsupported format

Many crawlers cap the image they will download. Meta’s guidance is to stay under 8 MB, but you should aim well below 1 MB — a clean PNG or JPEG at 1200×630 is comfortably under that. Avoid formats crawlers do not reliably render as previews, such as SVG and WebP; stick to PNG or JPEG for the og:image itself. An oversized or exotic file silently fails to load and you get a card with no picture.

6. The crawler is being blocked

If a human sees the image in a browser but the share card does not, a bot is being turned away. Check three places:

• robots.txt — make sure you are not disallowing facebookexternalhit, Twitterbot, LinkedInBot, or Slack’s Slackbot-LinkExpanding, and that the path to the image itself is crawlable.
• WAF / CDN / bot rules — Cloudflare, security plugins, and rate limiters frequently 403 these user-agents. Allowlist the official crawler agents.
• Auth or geo walls — if the page or image sits behind a login, paywall, or region block, the crawler gets the gate, not the content.

7. The tag is generated by JavaScript

Social crawlers read the raw HTML response. They generally do not execute your JavaScript, so any og:image injected client-side after load is invisible to them. View the page source with curl (or “View Source,” not DevTools’ Elements panel) and confirm the tag is in the initial HTML:

curl -s https://example.com/page | grep og:image

If nothing prints, your tag is being added too late. Render Open Graph tags server-side (or pre-render/SSG the page) so they exist in the first byte of the response.

8. The tag is in the wrong place or malformed

Open Graph tags must live in the document <head>, and they use the property attribute — not name:

<!-- Wrong: name= is for twitter:* and standard meta, not og:* -->
<meta name="og:image" content="https://example.com/card.png">

<!-- Correct -->
<meta property="og:image" content="https://example.com/card.png">

Other quiet breakers: duplicate og:image tags (crawlers may pick the wrong one), the tag placed in the <body>, or an unclosed tag earlier in the head that swallows it. One correct tag in the head beats five scattered ones.

9. X shows no image because twitter:card is missing

On X specifically, a missing card type often reads as “no image.” X falls back to your Open Graph image, but without an explicit card declaration it may render a cramped summary card — or nothing. Add one line:

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="https://example.com/card.png">

That guarantees the large-image card and gives X an explicit image to use.

A quick diagnostic order

When a card is blank, work through it like this:

1. Re-scrape in the platform’s debugger — rules out caching (#1).
2. View raw source and confirm an absolute og:image is present in the head (#2, #7, #8).
3. Open the image URL directly — check it returns a 200, not a 404/403/redirect (#3, #6).
4. Verify size and weight — 1200×630, under ~1 MB, PNG/JPEG (#4, #5).
5. Add twitter:card if X is the problem child (#9).

A reliable, scalable fix for most of these is to stop hand-managing per-page images and generate them from a template instead: the image is rendered server-side at exactly 1200×630 as a PNG, served from an absolute URL behind a single og:image tag, with the width, height and twitter:card values filled in correctly every time.

Fix it faster with Ogwave

That is exactly what Ogwave is built for. Paste any URL into the free preview to see what crawlers actually receive and get a corrected, copy-paste meta block — then point Ogwave at your sitemap to auto-generate a correctly sized, on-brand OG image for every page, so “OG image not showing” stops being something you debug one link at a time.