Your Open Graph Tags Are Correct. This Is Why the Wrong Image Still Shows Up.
Your Open Graph tags are correct. The og:title, og:description, og:image, and og:url are all properly set. You validate them with a preview tool and everything looks right. Then you share the URL on LinkedIn and the old image, the one from three months ago, appears in the link card. The update is live on your site. The preview is not.
This specific scenario has a name in developer circles: the OG cache problem. Understanding it requires knowing how Open Graph data is fetched, stored, and served, and why the update cycle between web pages and social platforms has a built-in delay that no tag update can bypass on its own.
The Open Graph protocol was introduced by Facebook in 2010, at the first F8 Developer Conference, as a way to give websites control over how their content appeared when shared. Before Open Graph, social platforms either scraped arbitrary page content to build link previews or offered no preview at all. Open Graph standardized the interface: a set of og: meta tags in the page head that specify exactly what title, description, and image a platform should use. Twitter later developed its own parallel system called Twitter Cards, and LinkedIn, Pinterest, and other platforms followed with support for Open Graph tags as well.
How the Open Graph Protocol Was Designed
The formal specification for Open Graph was authored by David Recordon and David Morin at Facebook, with input from the broader developer community. The protocol uses the same namespace mechanism as RDFa, the Resource Description Framework, which was itself developed by the W3C to embed structured data in HTML. The og: prefix identifies tags as Open Graph properties. Core required tags include og:title, og:type, og:image, and og:url. Optional tags specify audio, video, locale, site name, and description.
The type system in Open Graph includes not just "website" but also "article," "book," "profile," "music.song," "music.album," "video.movie," and others. Publishers setting og:type to "article" unlock additional properties: og:article:author, og:article:published_time, og:article:modified_time, and og:article:section. These extra properties inform how platforms categorize and display the shared content. An article link shared from a site with og:article:published_time set may be shown differently by platforms that use freshness signals for content ranking.
Facebook's initial open-sourcing of the Open Graph protocol contributed to its broad adoption. By 2011, Open Graph was integrated into major CMS platforms including WordPress, which added built-in og: tag support and later integrated the Yoast SEO plugin to give fine-grained control over each page's metadata. The standardization meant that a single set of tags could serve Facebook, LinkedIn, Slack, WhatsApp, iMessage link previews, and numerous other platforms simultaneously.
Why Platforms Cache OG Data
When someone shares a URL on a social platform, the platform's crawler visits the page, reads the og: meta tags from the HTML head section, and stores the result in an internal cache. The stored preview data, the title, description, and image, is then served to anyone who sees that shared post without requiring another crawl of the original page. This caching is necessary for performance at the scale social platforms operate at. Billions of URL shares occur daily across major platforms, and crawling the origin server for every share in real time would be both technically infeasible and harmful to origin servers.
The cache duration varies by platform and is not officially documented by all of them. Facebook's documented behavior through its developer tools indicates that OG data is cached until manually refreshed via the Sharing Debugger or until the platform's crawler revisits the URL on its own schedule, which may be days to weeks. LinkedIn has historically cached OG data for approximately seven days. Slack's link unfurling cache duration has varied over the platform's history and has been a persistent source of complaints from developers who update pages frequently.
The consequence is that when you update your og:image to fix an incorrect preview, every share of that URL made before the cache expires still shows the old image. The tag change is real and immediate on your server. The platform's cached version is what all existing embeds serve. New shares after a cache invalidation will show the updated image; existing shares typically do not.
Forcing a Cache Refresh
Facebook addresses this with their Sharing Debugger tool, which is available to anyone with a Facebook account. Entering a URL in the Sharing Debugger triggers an immediate re-crawl and updates Facebook's cached OG data for that URL. The tool also shows you what Facebook currently has cached, including the timestamp of the last crawl, the parsed values of each og: tag, and any warnings about tag misuse or missing recommended tags.
LinkedIn's Post Inspector serves the same function for LinkedIn's cache. Entering a URL triggers a re-crawl and shows the current parsed values. The LinkedIn Post Inspector also shows the scrape date so you can confirm whether you are seeing fresh or cached data.
Twitter's Card Validator allows you to see how Twitter is parsing your card metadata, though Twitter processes URLs in a different pipeline from Facebook and LinkedIn. Twitter Cards overlap significantly with Open Graph; if both og:image and twitter:image are set, Twitter uses twitter:image. If only og:image is set, Twitter falls back to it.
Slack provides an unofficial workaround: adding a query string to a URL, such as appending?v=2 or a timestamp, creates a technically different URL that Slack treats as uncached. This approach works but results in the new URL being tracked separately in analytics systems.
Image Requirements and Common Mistakes
The og:image specification has requirements that differ slightly between platforms. Facebook recommends 1200x630 pixels for full-size display in news feeds and link ads. Images below 200x200 pixels are typically not used for preview display at all and the platform falls back to text-only rendering. Images with extreme aspect ratios are cropped to a 1.91:1 ratio, which may cut off important parts of the image if the original is not designed with that crop in mind.
The og:image:width and og:image:height tags, though optional, affect how quickly a platform can display the preview without waiting to download the full image to determine its dimensions. Setting these tags accurately allows the platform to render the preview container immediately and load the image into the correct space, reducing perceived load time for link previews.
The og:url property introduces a less obvious failure mode. When you set og:url to a canonical URL that differs from the URL actually being shared, some platforms merge OG data from the canonical URL with the shared URL. Shares of a non-canonical version may display data cached from the canonical version, producing inconsistent previews depending on which URL the sharer copied. The safest practice is to set og:url to exactly the URL of the page, matching the canonical link tag.
What a Preview Tool Actually Tests
An Open Graph preview tool fetches the HTML of a URL, parses the og: tags from the head section, and renders a visual representation of what a link card would look like using those values. This tests what the tags currently say, not what a specific platform has cached.
Conclusion
Before publishing, preview tools let you verify the image renders at the correct size, the title does not truncate awkwardly, and the description fits the platform's character limit. After publishing but before sharing, preview tools confirm the tags are live and parsing correctly. After a cache problem, preview tools help isolate whether the issue is with the tags themselves or with a platform's cached version by showing you what is currently in the page source versus what a platform's debug tool shows as cached.
Both types of test are necessary because a correct page and a platform's incorrect cache can coexist. The tag is right. The cache is wrong. Knowing which problem you have determines which solution applies.
Frequently Asked Questions
Why is the wrong image showing up when I share my URL?
Social platforms cache Open Graph data when a URL is first shared. Updated OG tags may not appear until the platform's cache expires, typically days to weeks, or you manually force a refresh.
How do I force Facebook to update my Open Graph cache?
Use Facebook's Sharing Debugger tool. Entering your URL there triggers an immediate re-crawl and updates the cached OG data for that URL.
What size should an Open Graph image be?
Facebook recommends 1200x630 pixels for full-size display. Images below 200x200 pixels are typically not displayed. The standard aspect ratio is 1.91:1.