How to configure Open Graph tags

Open Graph is the metadata protocol Facebook introduced in 2010 that controls how a URL previews when someone shares it. LinkedIn, Twitter (via Twitter Cards), Slack, Discord, iMessage, and most chat platforms all read Open Graph tags. Get them right and your link shares with a polished card—big image, punchy title, focused description—that pulls clicks. Get them wrong and your link shares as a plain URL or, worse, with a stretched thumbnail cropped from a random decorative element. The tags themselves are simple <meta> elements, but the image dimensions, caching behavior, fallback chains, and platform-specific quirks catch everyone the first time. This guide covers the core og:* properties, the 1200x630 image standard, Twitter Card variants, debugging workflows, and the tags that genuinely matter versus the ones that are just noise.

The four tags you always need

Four Open Graph tags cover 95 percent of link-sharing behavior:og:title, og:description, og:image, andog:url. Every indexable page should have all four. Many platforms fall back to the HTML <title> tag when og:title is missing, and to the meta description when og:description is missing, but relying on the fallback means you lose the ability to write shorter, punchier copy tuned for social sharing as opposed to search results.

<meta property="og:title" content="Free JSON Formatter" />
<meta property="og:description" content="Format, validate, and minify JSON instantly. No login." />
<meta property="og:image" content="https://example.com/og/json-formatter.png" />
<meta property="og:url" content="https://example.com/tools/json-formatter" />

og:type and og:site_name

og:type tells the platform what kind of content the page represents:website, article, video.movie, music.song,book, or profile. Most pages use website; content-focused pages use article, which enables additional properties likearticle:published_time and article:author. og:site_nameis the human-readable name of your site, shown above the preview card on some platforms. Both are secondary to the four core tags but add polish.

og:image dimensions and format

The recommended og:image is 1200 pixels by 630 pixels, aspect ratio 1.91:1. This is the size Facebook, LinkedIn, Slack, and Twitter (when using summary_large_image) all render comfortably. Minimum supported is 600 by 315 pixels. Images smaller than that show as thumbnails next to the title rather than as a hero card. Maximum file size is generally 8 MB, but keep it under 500 KB for fast rendering. PNG and JPEG are both supported. GIF works on some platforms. WebP works on most modern platforms but fails on some older scraper implementations.

Recommended:   1200 x 630 px (1.91:1)
Minimum:       600 x 315 px
Max file size: ~8 MB (platform limit)
Target size:   < 500 KB for fast render
Formats:       PNG, JPEG (safest); WebP (most modern)

Specifying image dimensions explicitly

Add og:image:width and og:image:height to help platforms lay out the preview before the image downloads. This matters because many scrapers have a short timeout: if they cannot determine the dimensions quickly, they skip the image and fall back to a text-only card.

<meta property="og:image" content="https://example.com/og/home.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Dashboard showing JSON validation results" />

Twitter Card tags

Twitter reads both Open Graph and Twitter-specific meta tags, preferring Twitter-specific ones when both are present. The two main card types are summary (small square image) and summary_large_image (full-width 1.91:1 card, similar to Facebook). Include twitter:card, optionally twitter:site (your site’s Twitter handle), and twitter:creator (the article author’s handle). If you already have og:image and og:description, Twitter uses those unless you override with twitter:image and twitter:description.

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@yoursite" />
<meta name="twitter:creator" content="@author" />

Absolute URLs are required

The og:image and og:url values must be absolute URLs, not relative paths. Scrapers fetch these URLs independently, usually without the context of the referring page, so a relative path like /images/hero.png resolves to the scraper’s own domain and fails. Use https:// not http://for all values, and do not use protocol-relative //example.com/hero.pngbecause some older scrapers cannot parse it.

Caching and the Facebook debugger

Facebook, LinkedIn, and most platforms cache scraped metadata for days or weeks. If you update og tags and share the URL again, you will see the old preview until the cache expires. Facebook’s Sharing Debugger at developers.facebook.com/tools/debug/ shows exactly what Facebook sees and lets you force a refresh with “Scrape Again.” LinkedIn has a similar Post Inspector tool. Twitter’s Card Validator existed but has been deprecated; to force a Twitter refresh, append a dummy query parameter to the URL. Test every new page in at least one debugger before announcing a launch.

Localization with og:locale

og:locale specifies the language and region (like en_US,fr_FR, pt_BR). For multi-language sites,og:locale:alternate lists additional supported locales. Localized share previews are rare outside Facebook, but the tags signal correct language to downstream translation tools and accessibility software.

Article-specific properties

When og:type is article, add article:published_time(ISO 8601 datetime), article:modified_time, article:author(a URL or name), article:section, and article:tag. These surface in some rich shares on LinkedIn and Facebook and help downstream tools like Pocket and Instapaper categorize content.

Dynamic og:image generation

Many sites generate og images on demand using serverless functions or edge workers: Vercel OG, Cloudinary, or a homegrown Puppeteer job. The generator takes the page title and a template and produces a 1200x630 PNG with branded typography. This scales well for thousands of pages without designing each image manually. Cache the output aggressively because every social share will fetch it. A stale cache of a good image is better than a cache miss during a viral moment.

Common mistakes

Relative image URLs. Scrapers cannot resolve relative paths. Always use absolute https:// URLs for og:image and og:url.

Wrong aspect ratio. Images that are not near 1.91:1 get cropped unpredictably—often cutting off the title text or your logo. Design for 1200x630 and let platforms scale down.

Forgetting og:url. Without og:url, some platforms use the URL the user pasted, which may include UTM parameters or tracking IDs that vary per share. Set og:url to the canonical URL.

Not testing in the debugger. CMS previews do not match real scrapers. Always test with Facebook Sharing Debugger and a real share on at least two platforms before launch.

Caching issues after updates. Platforms cache for days. Use the Facebook Debugger’s force-refresh button to update the cache for a specific URL.

Text too small on the og image. The image renders at small sizes on mobile. Headlines below 40 pixels tall in the source usually become unreadable on a phone. Design at actual render size.

Mixing property and name attributes. og:* tags useproperty=; twitter:* tags use name=. Mix them up and some scrapers ignore the tags entirely.

Run the numbers

Build a complete og tag set in seconds with the Open Graph generator. Pair with the meta tag generator for the broader set of head tags (charset, viewport, canonical) and the schema markup generator to add JSON-LD that unlocks rich snippets in search as well as polished cards on social.