Configure Your Metadata
Fill in the fields below. Your live social previews and meta tag code will update automatically as you type.
Facebook / Meta Link Preview
X (Twitter) Card Preview
LinkedIn Link Preview
Generated Meta Tag Code
Copy and paste these tags into the <head> section of your HTML document. They instruct social media crawlers on how to display your link.
Open Graph and Twitter Card Attribute Reference
A complete reference of all supported meta properties - which are required for valid structured data and which are optional enhancements.
| Property / Name | Tag Type | Required? | Recommended Value / Notes |
|---|---|---|---|
og:title |
Open Graph | Required | The title of the shared page. Keep under 60 characters to prevent truncation in most feeds. This is the most influential property for click-through rate. |
og:description |
Open Graph | Required | A short summary of the page content. Between 100 and 155 characters is ideal. Compelling descriptions directly increase click-through rates on shared links. |
og:image |
Open Graph | Required | Full absolute URL to the preview image. Minimum 200x200px, ideal 1200x630px. Use JPG or PNG. Keep file size under 8MB. An attractive image is the single biggest driver of social engagement. |
og:url |
Open Graph | Required | The canonical URL of your page - the preferred permanent address. Must include the https:// scheme. Prevents duplicate content issues when multiple URLs point to the same page. |
og:type |
Open Graph | Required | Declares the nature of the content. Use website for standard pages and article for blog posts or news. The article type unlocks additional publishing metadata properties. |
og:site_name |
Open Graph | Optional | The name of your website or brand. Displayed in small text above the title on Facebook. Helps users instantly recognize the source of a shared link and builds brand recognition. |
og:locale |
Open Graph | Optional | The language and region of the content. Defaults to en_US. Use standard locale codes like en_GB, fr_FR, or de_DE for international pages. |
og:image:width |
Open Graph | Optional | Width in pixels of the og:image. Providing explicit dimensions lets the crawler skip a separate image download to determine size, which can speed up preview rendering. |
og:image:height |
Open Graph | Optional | Height in pixels of the og:image. Pair with og:image:width for complete dimension declarations. The standard Open Graph aspect ratio is 1.91:1 (e.g., 1200 x 628 pixels). |
og:image:alt |
Open Graph | Optional | A text description of the preview image for accessibility. Screen readers used by visually impaired users will read this aloud when the link preview is encountered. |
twitter:card |
Twitter Card | Required | Defines the card layout format. Use summary_large_image for a wide banner image (highly recommended for engagement) or summary for a compact card with a square thumbnail. |
twitter:title |
Twitter Card | Required | The title displayed on the X (Twitter) card. If absent, X falls back to og:title. Keep under 70 characters for full display without truncation in the feed. |
twitter:description |
Twitter Card | Optional | The description shown on X cards. Falls back to og:description if omitted. Maximum 200 characters, though X may truncate at shorter lengths depending on the card display context. |
twitter:image |
Twitter Card | Optional | Full absolute URL to the image for the X card. Falls back to og:image if absent. For summary_large_image, minimum 300x157px. For summary, images are cropped square. |
twitter:site |
Twitter Card | Optional | The @username of the X account associated with the website. Displayed on the card in some contexts. Format as @yourbrand with the @ symbol included. |
twitter:creator |
Twitter Card | Optional | The @username of the individual content creator or author. Particularly relevant for article-type content. Helps attribute authorship directly within the X card display. |
article:published_time |
Open Graph (Article) | Optional | ISO 8601 timestamp of when the article was published. Only applicable when og:type is set to article. Example format: 2025-01-15T08:30:00+00:00. |
The Complete Engineering Guide to Open Graph Protocol and Social Optimization
Everything you need to understand, implement, and troubleshoot structured social metadata - written for developers and content teams at all levels.
The Open Graph Protocol (OGP) is a standardized set of HTML meta tags, originally created and published by Facebook in 2010, that enables any web page to become a rich object within the social graph. When you share a URL on platforms like Facebook, LinkedIn, Slack, iMessage, or Discord, those platforms do not simply display the raw URL as plain text. Instead, they dispatch an automated software agent called a crawler (also called a bot or scraper) that visits your page, reads the document's HTML source, and extracts structured data from the <head> section to build a rich preview card.
Without Open Graph tags, platforms must guess which title, image, and description to use. This typically results in wrong titles pulled from an H1 tag, randomly selected images pulled from the first image element on the page, or no image at all. The visual result is a plain, unappealing link that communicates nothing about the page's value to the reader. Studies by social media analytics firms consistently show that links with well-configured preview images receive 3 to 5 times more clicks than plain text links. In marketing and analytics this is referred to as improving the Click-Through Rate (CTR) - the percentage of people who see a shared link and actually click it. The Open Graph Protocol gives you precise control over what the crawler finds and what the preview card displays, making it one of the highest-return investments in technical content marketing.
The specification originally defined four required properties: og:title, og:type, og:image, and og:url. Over the years, every major platform has extended this core schema with their own proprietary additions. Twitter (now X) created the Twitter Cards specification as a parallel system, though it largely mirrors Open Graph properties. LinkedIn, Slack, and other platforms all consume Open Graph as the primary source of truth for link unfurling. This means configuring these four base tags correctly provides foundational coverage across virtually every major platform where your content could be shared.
When a user pastes your URL into Facebook, X, LinkedIn, or a messaging app, the platform's backend infrastructure immediately dispatches a crawler bot - a programmatic HTTP client that makes a GET request to your URL exactly as a browser would. The critical difference is that social media crawlers do not execute JavaScript. They read only the raw HTML source code that your server delivers in its initial response. This is an essential architectural constraint with significant implications for modern web development.
If your website is a Single Page Application (SPA) built with React, Vue, Angular, or similar frameworks, the page content is often generated dynamically by JavaScript after the initial HTML payload is delivered. Because the crawler does not run JavaScript, it may receive an essentially empty HTML shell that contains none of your Open Graph tags. This is a very common reason why social previews fail on SPA-based sites. The solution is server-side rendering (SSR), static site generation (SSG), or a dedicated prerender service that delivers fully populated HTML to bot user agents.
Crawlers identify themselves via the HTTP User-Agent header in their requests. Facebook's crawler is identified as facebookexternalhit, LinkedIn's is LinkedInBot, and X's is Twitterbot. Your server logs will contain these entries each time someone shares your URL. Once the crawler receives your HTML, it parses the document head from top to bottom, searching specifically for <meta> tags that match the Open Graph schema (property="og:...") and the Twitter Card schema (name="twitter:..."). The values of the content attribute in each matching tag are extracted and stored in the platform's cache. This cached data is what gets displayed in every instance of a shared preview for that URL until the cache is refreshed or forcibly cleared.
Your meta tags must be placed in the <head> section of the HTML document before the closing </head> tag. While the exact placement within the head does not technically matter to parsers, placing them as early as possible - ideally before stylesheets and scripts - is considered best practice. It reduces the chance that a slow-loading resource interrupts the parser before your meta data is encountered. Always use absolute URLs (beginning with https://) for the og:image and og:url values. Relative paths like /images/preview.jpg are meaningless to a remote crawler that has no concept of your site's root directory.
The preview image - declared via og:image - is without question the single most impactful element of a social share card. It determines whether someone stops scrolling and reads your content or keeps scrolling past it. Getting the technical specifications right ensures your image renders sharply without cropping, distortion, or rejection by the platform's image validator.
The universally recommended resolution for Open Graph images is 1200 x 630 pixels, which corresponds to a 1.91:1 aspect ratio (sometimes approximated as 2:1). This exact size renders perfectly on high-DPI and Retina displays without upscaling artifacts, and is used natively by Facebook, LinkedIn, and most other platforms. LinkedIn technically specifies 1200 x 628 pixels (a trivially different 1.91:1 approximation), but images at 1200 x 630 render without any visible difference. For X (Twitter) using the summary_large_image card type, the minimum resolution is 300 x 157 pixels, but providing the full 1200 x 630 image ensures high-quality display on all device types and screen densities.
For the standard summary card type on X, the image is cropped to a square. You should ensure that the central focus point of your image sits squarely in the middle of the frame so it is not cut off when the platform crops the sides. For images that must work across both card types simultaneously, designing a center-weighted composition that looks good in both 1.91:1 landscape and 1:1 square aspect ratios is the recommended approach.
Regarding file format, JPEG (JPG) is the preferred format for photographic images due to its excellent compression. Facebook enforces a maximum file size of 8MB for og:image assets, though you should practically target under 1MB for fast crawler fetching and efficient CDN caching. Use PNG for images requiring transparency or sharp text overlays, such as custom preview cards with brand logos and typography. Facebook, X, and LinkedIn all support JPG, PNG, and GIF formats. Animated GIFs are technically supported by Twitter for summary_large_image cards, but support is inconsistent across platforms and not recommended for production use. WebP format is not universally supported by all platform crawlers and should be avoided for og:image assets even if you use it for your standard page images.
Beyond the image itself, ensure the file is publicly accessible. Images sitting behind authentication walls, on localhost, or served from IP addresses that block common bot user agents will simply fail to load for the crawler. If you are developing locally, your og:image must still point to a live, publicly reachable URL. Use a CDN or image hosting service for your preview images to guarantee global availability and fast response times for crawlers operating from any geographic region.
Once a social media platform crawls your URL and builds a preview card, it stores that data in its internal cache for a period that varies by platform - typically anywhere from 30 minutes to 30 days. This means that if you update your Open Graph tags after a URL has already been shared, those sharing that link will continue to see the old, cached preview until the platform refreshes its stored data. This is a common point of frustration for developers who have fixed their tags but cannot see the change reflected. The solution is to manually trigger a cache invalidation using each platform's dedicated developer debugging tool.
Facebook Sharing Debugger is available at developers.facebook.com/tools/debug. Enter your URL into the input field and click "Debug." The tool will show you the cached data currently stored for your URL. To force a refresh, click the "Scrape Again" button. Facebook will re-crawl your page immediately and update its cache with whatever Open Graph data it finds in your current HTML. You may need to click "Scrape Again" a second time to see the updated properties. This is the most important debugger to check, as Facebook is also the reference implementation of the Open Graph Protocol specification.
X (Twitter) Card Validator was historically available at cards-dev.twitter.com/validator, but X has deprecated this public tool. Cache invalidation on X now occurs naturally over time (typically within 1 to 7 days), or you can use the X API's card endpoint if you have API access. For time-sensitive situations, appending a tracking query parameter to your URL (e.g., ?v=2) technically creates a new URL in the platform's cache system, which will be crawled fresh. However, this approach also changes the URL being shared and should only be used when absolutely necessary.
LinkedIn Post Inspector is available at linkedin.com/post-inspector. Like the Facebook Debugger, it allows you to enter a URL, view the currently cached Open Graph data LinkedIn has stored, and force a re-crawl by clicking "Inspect." LinkedIn's cache typically has a shorter expiration window of around 7 days, but forced inspection updates it immediately. This tool is valuable for verifying your og:title and og:image before sharing content on LinkedIn, where professional audiences place high expectations on content presentation quality.
Beyond the platform-specific tools, you should validate your meta tags using general-purpose tools like opengraph.xyz or the Meta Tags validator at metatags.io. These tools simulate a crawler read from a neutral perspective and show you exactly what data is present in your document head, helping you catch configuration errors before they are cached by any platform. Build cache verification into your content publishing workflow as a final step before distributing links to ensure every share results in the intended high-quality preview.
When your page is a blog post, news article, or editorial content, setting og:type to article unlocks a collection of article-specific Open Graph properties that provide richer metadata for publishing platforms and news aggregators. The most important are article:published_time, article:modified_time, and article:author. These properties accept ISO 8601 datetime strings (e.g., 2025-06-15T09:00:00+00:00) and fully qualified author profile URLs respectively. While Facebook is the primary platform that actively uses these properties in its feed ranking signals, they also communicate publishing provenance to news indexers, RSS aggregators, and content syndication platforms.
The Open Graph specification allows for multiple og:image tags on a single page - a feature that is rarely used but can be valuable in specific scenarios. When multiple og:image tags are present, some platforms (primarily Facebook) allow the person sharing the URL to select which image to use in their post. This is useful for product pages or gallery pages where multiple representative images exist. Simply include multiple sequential <meta property="og:image" content="..." /> tags, each followed by its corresponding og:image:width, og:image:height, and optionally og:image:alt tags. The first declared image is always used as the default selection.
Schema.org structured data is a separate but complementary system to Open Graph. Where Open Graph controls social link previews, Schema.org JSON-LD markup (injected via a <script type="application/ld+json"> block in the document head) communicates structured information to search engines, primarily Google. Properly implemented Schema.org markup can result in rich results in Google Search - enhanced listings showing star ratings, recipe details, event dates, product prices, or FAQs directly in the search engine results page (SERP). While Schema.org and Open Graph serve different systems, both target the same fundamental goal of making your content more machine-readable and visually distinctive across discovery surfaces. For maximum content marketing impact, implementing both standards together is strongly recommended.
One nuance that catches many developers off guard is the og:url canonical behavior. The og:url property should always match the canonical URL of the page - the preferred, permanent address you want associated with this content. If your page is accessible at multiple URLs (e.g., with and without trailing slashes, with and without tracking parameters, via HTTP and HTTPS), the og:url value ties all social engagement metrics to a single canonical identity in Facebook's graph database. This means likes, shares, and comments from all URL variants get aggregated under the canonical URL. Failing to set og:url correctly can fragment your social engagement data across multiple URL variants, making it appear your content is performing worse than it actually is in analytics dashboards.
Disclaimer: Social media platforms cache metadata strictly. While this tool generates standard compliant markup, platforms may take time to update your shared links unless cleared via their specific developer debuggers. Use Facebook Sharing Debugger, LinkedIn Post Inspector, or X Card Validator to force a cache refresh after updating your meta tags.