Why Your Link Preview Image Isn't Showing

You paste your link into Slack and get a bare blue URL. Or a card with a headline and a grey box where the image should be. Or, worse, the right headline paired with an image from a completely different page you published three months ago. The page looks fine in a browser, the tag looks fine in your template, and nothing anywhere reports an error.

Link previews fail silently by design — a scraper that cannot find or fetch an image just renders the card without one. That makes this a debugging problem rather than a writing problem, and it has a small, finite list of causes. This post works through them in the order they are worth checking. For the broader context of how Open Graph fits with the rest of your metadata, see The Complete Guide to Meta Tags, and if the tags themselves are unfamiliar territory, start with what are meta tags.

1. The tag is missing, or uses the wrong attribute

Start by looking at what the scraper sees, not what your template says. Fetch the raw HTML:

curl -sL https://example.com/your-page | grep -i 'og:image'

Use curl, not browser dev tools. Dev tools show the DOM after JavaScript has run; curl shows what a scraper that does not execute JavaScript receives. That difference is itself a cause, covered below.

If nothing comes back, the tag is absent. If something comes back, check the attribute carefully:

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

<!-- silently ignored -->
<meta name="og:image" content="https://example.com/images/card.jpg">

Open Graph is built on RDFa and requires property. Using name produces valid HTML that is invisible to every major scraper — the most common markup-level cause of a missing image, and confusing because the neighbouring twitter:card tag genuinely does use name.

2. The URL is relative

<!-- fails -->
<meta property="og:image" content="/images/card.jpg">

<!-- fails -->
<meta property="og:image" content="//example.com/images/card.jpg">

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

The Open Graph specification requires an absolute URL. A relative path resolves correctly in a browser and resolves to nothing in a scraper, which has no base URL context to work from. Protocol-relative URLs are almost as bad — several scrapers refuse them.

Include the full https:// scheme, the host, and the path. If your site serves both www and apex hostnames, use whichever one your canonical uses so everything stays consistent.

3. The image is too small

Two thresholds matter, and missing either produces a different symptom:

• Below roughly 200x200 pixels, most platforms discard the image entirely and render a text-only card. This is the case where "the image is not showing" is literally true.
• Below roughly 600x315, the image is accepted but rendered as a small square thumbnail beside the text rather than a full-width banner. The card looks cramped and slightly broken even though every tag is correct.

The target is 1200x630 pixels at a 1.91:1 aspect ratio, which is what platforms design their large card layouts around. Also keep the file under about 5 MB — some scrapers abandon a download that exceeds their budget, producing an intermittent failure that is maddening to diagnose because it sometimes works.

If you are unsure what your current image measures, or need to produce a correctly proportioned version from an existing asset, the Image Resizer reports exact dimensions and aspect ratio and outputs a resized copy without uploading the file anywhere.

Format matters too. Use JPG or PNG. WebP and AVIF support across scrapers remains patchy in 2026, and a scraper that cannot decode the image treats it as absent.

4. The platform cached an earlier version

This is the cause behind almost every "I fixed it and it still shows the old one" report. Platforms scrape a URL once, cache the result hard — often for a week or longer — and do not re-check because your HTML changed. If a link was shared before the tag existed, or with a previous image, that first scrape is what everyone continues to see.

Changing the markup does nothing on its own. You have to force a re-scrape, and every major platform ships its own preview-refresh tool for exactly this:

• Facebook — the Sharing Debugger, which shows the scraped properties and has a "Scrape Again" button.
• LinkedIn — the Post Inspector, which re-fetches and displays the resulting card.
• X — the Cards validator surface; X also re-scrapes on its own more readily than the others.
• Slack, Discord, WhatsApp — no public debugger. They generally expire on their own timers, and Slack's unfurl cache can be nudged by appending a harmless query parameter to test with.

Run the URL through the relevant tool after any image change. These also double as diagnostics: Facebook's debugger reports exactly which properties it found and which it rejected, which frequently identifies the real problem in one pass. For quick testing, appending ?v=2 fetches fresh because platforms key their cache to the exact URL string — just do not share the parameterised version publicly, or engagement splits across two records.

5. The tags are injected client-side

If your framework builds the <head> after hydration, a scraper that does not run JavaScript sees an empty head. Facebook's and LinkedIn's crawlers are conservative here; Slack and X are somewhat more capable but not reliably so.

This is exactly what the curl check in step one detects: if curl returns nothing but dev tools show the tag, your metadata is client-side and needs to be server-rendered. Every modern framework can emit metadata at request or build time — use it for anything shareable.

6. The image or page is not publicly reachable

Scrapers are anonymous: no cookies, no session, no credentials. Any of the following blocks them:

• The page or image sits behind basic auth, a staging password, or a login wall.
• A CDN or WAF rule challenges unfamiliar user agents, or rate-limits the scraper's range.
• robots.txt disallows the image directory. Several scrapers honour robots directives, so a blanket Disallow: /assets/ can hide the image.
• The image is served over http while the page is https, and the mixed-content reference is dropped.
• A hotlink-protection rule rejects requests with no referrer, which is what a scraper sends.

Verify the image URL by fetching it in a private window with no session, or with curl -I and checking for a 200 and an image/* content type. If that fails, no amount of tag-fixing will help.

7. Multiple or conflicting tags

If your CMS emits one og:image and a plugin emits another, the scraper takes the first it encounters — which may not be the one you edited. Count them in the raw HTML with curl -sL https://example.com/your-page | grep -c 'og:image'. More than one on a page that should have a single image means two systems are both writing tags; fix the source rather than reordering, or the next template change reintroduces it. The same conflict shows up when a stale twitter:image overrides a corrected og:image on X while every other platform shows the new one.

A checklist that resolves most cases

1. curl the live URL and confirm exactly one og:image tag exists, using property.
2. Confirm the value is an absolute https:// URL.
3. Confirm the image is at least 1200x630, JPG or PNG, under 5 MB.
4. Fetch the image URL anonymously and confirm a 200 with an image content type.
5. Force a re-scrape through the platform's own debugger.
6. Re-share and verify.

To get the markup right from the start rather than debugging it later, build the block with the Open Graph Generator, which emits correct property attributes and warns on relative URLs, and add the card layout with the Twitter Card Generator. The Meta Tag Generator covers the search-side block in the same pass. For the reasoning behind which Open Graph tags are worth setting at all, Open Graph Tags: The Five You Actually Need is the shorter path.

All of these run entirely in your browser, so unpublished URLs and pre-launch artwork never reach a server.

The underlying lesson

Preview images fail quietly, which means they fail late — usually the moment a colleague shares the link in public. Check the card before the post goes out, not after: generate the tags, deploy, run the URL through one platform debugger, confirm the image renders. Under a minute, and an entire category of embarrassment disappears.