Why your link preview image is not showing
Almost always one of three things: the platform cached a scrape of your page from before the image existed, your og:image is a relative path instead of a full URL, or the tag is being added by JavaScript and most scrapers do not run JavaScript; Apple says its Messages previews do not.
You can tell which one it is in about two minutes. Work through the checks below in order, because the cheap ones rule out the expensive ones.
Check 1: look at the HTML the scraper sees, not the page you see
This is the check that saves the most time and it is the one people skip. Your browser shows you the rendered DOM. A social scraper reads the raw HTML that came back in the first response, and that is often a different document.
View source rather than inspecting the element, and search for og:image. Or pull it from the command line:
curl -sL https://example.com/your-page | grep -i "og:"
If the tag is not in that output, the preview is not broken. To a scraper that does not run JavaScript, which is most of them, the tag does not exist. That happens when the meta tags are injected client side by a framework, a tag manager, or a plugin that runs after page load. The fix is to render the tags server side or put them in the static HTML.
If the tag is there, read the value carefully before moving on.
Check 2: is the image URL absolute?
og:image needs a complete, absolute URL including the scheme and the domain:
<meta property="og:image" content="https://example.com/images/preview.png">
Not /images/preview.png, and not //example.com/images/preview.png. A relative path works fine in an <img> tag, but Open Graph expects a full http:// or https:// URL, and a relative one fails unpredictably across platforms. Mixed protocols cause the same trouble: an http:// image on an https:// page can cause a preview that appears for some platforms and not others.
While you are looking, confirm the URL actually loads when pasted into a private browsing window with no session. A preview image sitting behind a login, a staging password, a hotlink protection rule, or a robots.txt disallow will not be fetched.
Check 3: clear the cache on the platform's side
Every major platform caches what it scraped. If you shared the URL before the image was in place, the platform is showing you a stored answer and will keep doing so until you force a refresh. This is what is behind a preview that shows the old image after you have already fixed the tag. If you replaced the image file but kept its URL, rename the file too. Meta says images are cached by URL and are not updated until the URL changes.
-
Facebook: open the Sharing Debugger at
developers.facebook.com/tools/debug/, paste the URL, and ask the debugger to scrape the page again. It will also list warnings about the tags it found. Note that the Sharing Debugger requires you to be signed in to a Facebook account. If you do not have one, you will need someone who does to run this step for you. -
LinkedIn: open the Post Inspector at
linkedin.com/post-inspector/and inspect the URL. Inspecting re-scrapes, which is what refreshes the stored copy. It will not fix a post that is already in the feed, though: LinkedIn documents that the refreshed image applies to new shares only, so an existing post keeps the old preview; to show the new one, share the link in a new post. -
Slack, Discord, iMessage and the rest: these generally have no public purge tool. Slack keeps its copy for around 30 minutes. The usual workaround is to append a harmless query string, for example
?v=2, which is a different URL and so gets a fresh scrape. Use that to confirm the tags are right, then share the clean URL once the cache expires.
If a fresh scrape fixes it, you are done, and the tags were correct all along.
Check 4: the image itself
Once the tag is present, absolute and publicly reachable, the remaining failures are properties of the file.
- Shape. The widely used large preview is 1200 x 630 pixels, roughly a 1.91:1 ratio. A square or portrait image will often be shown cropped, or demoted to a small thumbnail beside the text rather than a full width card.
- Minimum size. Very small images get rejected or rendered as a tiny icon. Facebook's documentation gives 200 x 200 pixels as the absolute floor, and Meta documents 600 x 315 pixels as the minimum for a large-format card. Below that, expect the small thumbnail beside the text rather than the full width card.
- File size. Keep the file comfortably small. Facebook's documented ceiling is 8 MB, but a preview image that takes seconds to fetch is a preview image the scraper may give up on.
- Format. Use PNG or JPEG. Meta's documentation lists JPEG, GIF and PNG, so other formats such as SVG and WebP are a risk.
- Text in the image. Nothing breaks, but the card is small on a phone. Small text in a preview image is often unreadable at the size platforms actually render it, so check your image at the size it will be seen rather than at full resolution.
Check 5: conflicting or duplicated tags
Two og:image tags on the same page is a problem you should not leave in place. The Open Graph protocol says the first tag is given preference during conflicts, but do not count on every platform following that, and do not rely on ordering to pick the right image. This happens constantly on sites where a theme sets Open Graph tags and an SEO plugin sets them again. Search the raw HTML for og:image and count the matches. There should be exactly one per page unless you are deliberately offering multiple images.
Two neighboring tags are worth checking in the same pass:
-
og:url. If it points at a different URL than the one being shared, the scraper may follow it and read that page's tags instead. Make it match the canonical URL of the page. -
twitter:cardandtwitter:image. If your preview works everywhere except X, look for atwitter:imagethat points somewhere stale.
Redirects belong here too. A URL that redirects to a different page will normally be scraped at its destination, so a preview that looks wrong on a shortened or campaign tagged link is often just the destination's tags showing through.
Check 6: the URL you are sharing is not the URL you are testing
The last one, and the quietest. Campaign parameters make a different URL. On platforms that cache by exact URL, such as Slack, example.com/page and example.com/page?utm_source=newsletter can hold two different cached scrapes. If a link works when you paste it plainly and fails in your newsletter, test the exact tagged string, not the clean one.
If the two versions of your link also disagree about capitalization, you have a second problem underneath this one, and why UTM names split your reports covers that.
Put the tags in right the first time
The reliable fix order is: write correct tags, confirm they appear in the raw HTML response, then force one re-scrape on each platform you care about.
The Benchvale Open Graph generator writes the tag block for you and sketches LinkedIn, X, Facebook and Slack cards, so you can catch a title or description that will be cut before the post is out. It runs entirely in your browser, so the page you are describing never gets sent anywhere.
Related
The Open Graph generator writes the tags and sketches approximate LinkedIn, X, Facebook and Slack cards, so you can spot a title that will be cut. It doesn't fetch your page or load your image, so check the image URL itself as in Check 2. The UTM builder handles the campaign parameters that ride on the same links, and the marketing tools hub has the rest.