Open Graph Meta Tags: A Complete Guide to Social Link Previews
Open Graph meta tags are <meta property="og:…"> tags you put in the <head> of an HTML page. They control the title, description, and image shown when someone shares your link on Facebook, LinkedIn, Slack, Discord, WhatsApp, and most other platforms. Define them once and nearly every network renders a rich preview instead of a bare URL. X (Twitter) reads its own Twitter Card tags but falls back to your Open Graph tags when the matching one is missing, so a single well-built set of tags covers almost everywhere a link can travel.
That one protocol is the difference between a link that shows a headline, a summary, and a crisp 1200×630 image, and a naked address nobody clicks.
This guide walks through the full set of meta tags for social sharing: the four required Open Graph tags, og:image sizing rules, the Twitter Card fallback, how each platform renders and caches previews, the mistakes that leave shares blank, and how to debug the result after you deploy.
What are Open Graph meta tags?
Open Graph is an open protocol, originally created at Facebook and documented at ogp.me, that lets any web page describe itself as a rich object. Instead of guessing what your link is about, a platform reads a handful of tags and turns them into a preview card.
The syntax is a plain HTML meta tag with a property attribute and a content value, placed inside the document <head>:
<meta property="og:title" content="How Open Graph Tags Work">Note the property attribute. Classic HTML meta tags for SEO (the meta description, robots, viewport) use name. Open Graph uses property, and Twitter Card uses name again. Getting that attribute right matters; a crawler that expects property="og:title" will not read name="og:title".
Almost every platform that turns a link into a card reads Open Graph: Facebook, LinkedIn, Slack, Discord, WhatsApp, Pinterest, and Telegram all speak it. X is the notable exception. It prefers its own twitter:* tags but falls back to your og:* tags for anything it can’t find, which is why you rarely need to duplicate them.
Open Graph sits alongside the classic SEO meta tags rather than replacing them. The <title> and the canonical link still drive search; the meta description still shapes your search snippet. Open Graph tags don’t touch rankings; they own the social card. A complete <head> usually carries all three families together.
Writing these by hand is repetitive and easy to get subtly wrong. The Meta Tag Generator builds the whole block from a short form, previews it live, and keeps the tricky details (attribute names, absolute URLs, image dimensions) consistent so you don’t have to remember them.
The core Open Graph tags you actually need
Open Graph defines dozens of properties, but a good share needs only a handful. Start with the required four, add a description, and stop there for most pages.
The four required tags: og:title, og:type, og:image, og:url
Four tags are mandatory under the protocol. Miss one and platforms either drop the card or fill in a poor guess.
<meta property="og:title" content="How Open Graph Tags Work">
<meta property="og:type" content="website">
<meta property="og:image" content="https://example.com/og/cover.png">
<meta property="og:url" content="https://example.com/open-graph-guide">og:title is the bold headline on the card. og:type classifies the object (more on that below). og:image is the preview picture, and it must be an absolute HTTPS URL. og:url is the canonical address of the page, which platforms use to deduplicate shares and aggregate engagement.
og:description and how it differs from the SEO meta description
og:description is the short summary printed under the title on a share card:
<meta property="og:description" content="A practical guide to og:title, og:image and Twitter Card tags.">It is a different tag from the SEO <meta name="description">, and it serves a different reader. The meta description competes for clicks in a Google results page and is measured against roughly 155 characters. The Open Graph description is read on a social card, where space is tighter and the first sentence carries the weight. If you leave og:description out, most platforms fall back to your meta description, so you can often skip it. Write a dedicated one only when the social hook should differ from the search snippet.
og:type and what it unlocks
og:type tells platforms what kind of thing your page is. The common values are website, article, product, and profile. A homepage or landing page is a website; a blog post is an article.
Choosing article unlocks extra properties and features that a plain website type can’t use:
<meta property="og:type" content="article">
<meta property="article:published_time" content="2026-07-16T00:00:00Z">
<meta property="article:author" content="Ada Lovelace">Those article:* tags feed publish dates and bylines into cards, and they qualify the page for Pinterest Rich Pins, which pull structured data straight from your Open Graph markup. Set og:type to article on posts and to website on everything else, and the matching fields follow.
Here is a reference for the tags most pages actually use:
| Tag | What it controls | Example value |
|---|---|---|
og:title | Headline shown on the card | How Open Graph Tags Work |
og:type | Object type: website, article, product, profile | article |
og:image | Preview image (absolute HTTPS URL) | https://example.com/og/cover.png |
og:url | Canonical URL of the page | https://example.com/open-graph-guide |
og:description | Summary under the title | A practical guide to social meta tags. |
og:site_name | Name of the overall site | Example |
og:locale | Content language and region | en_US |
og:image sizes, ratio, and the rules that break shares
The image is the part of a preview people see first, and it is where most shares fall apart. Get the og:image size and format right and one file works everywhere.
The 1200×630 (1.91:1) universal standard
The recommended og:image size is 1200×630 pixels, a 1.91:1 aspect ratio. That single image renders correctly on Facebook, LinkedIn, Slack, Discord, and X’s summary_large_image card, so you don’t need a different file per platform.
Size floors matter too. Facebook ignores any image smaller than 200×200 and shows a cramped square thumbnail for anything under 600×315. Below 1200 pixels wide, large cards start to look soft. Aim for 1200×630 and you clear every threshold at once.
Why og:image:width and og:image:height matter
When a platform first meets your link, it hasn’t downloaded the image yet; it fetches that asynchronously. If you declare the dimensions up front, the platform can reserve the right space and lay the card out immediately:
<meta property="og:image" content="https://example.com/og/cover.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Open Graph guide cover with the title in large type">Skip these and the very first share of a page can render blank while the crawler catches up. Add them and the card is correct on the first paste. The og:image:alt tag describes the image for screen readers on platforms that support it.
File format and size
Use JPG or PNG. Both decode reliably across every crawler, which is the whole point of an og:image: it has to render on servers you don’t control. Keep the file under 1 MB as a rule of thumb, and under 300 KB for WhatsApp, which is stricter than the rest. If your export is heavier, run it through the image compressor to pull it below 1 MB without visibly hurting quality.
It’s tempting to reach for a modern format here, but this is the one place to resist. Newer formats save bytes for browsers, yet some social crawlers decode them inconsistently, so a WebP or AVIF og:image can come back blank on a platform that can’t read it. The trade-offs are covered in the WebP vs AVIF vs JPEG guide; for share images specifically, stay on JPG or PNG. Because platforms crop the edges differently, keep your logo and headline inside a centered 1080×600 safe zone so nothing important gets clipped.
The absolute-HTTPS-URL rule
og:image and og:url must be full https://… URLs, not relative paths. A path like /cover.png resolves fine in your editor and on your live page, but a crawler fetching your URL has no base to resolve it against, so the share comes back empty. The image also has to be publicly reachable: if robots.txt blocks the crawler or the file sits behind auth, the preview stays blank.
One more constraint decides everything above: crawlers do not run JavaScript. Facebook, LinkedIn, WhatsApp, Telegram, and Discord fetch your raw HTML and read what’s there. Tags injected client-side by a framework after page load are invisible to them, so your Open Graph tags must live in server-rendered or static HTML.
Twitter/X Cards: one tag, then fall back to Open Graph
X uses its own Twitter Card meta tags, but the overlap with Open Graph means you write far less than you’d expect. In practice you add one tag and let the rest fall back.
twitter:card is the one required Twitter tag
X renders no card at all unless twitter:card is present, even when you have a complete set of Open Graph tags. It is the single required Twitter Card tag:
<meta name="twitter:card" content="summary_large_image">The value picks the layout. summary_large_image gives the big banner card built for a 1200×630 image. summary gives a compact card with a small square thumbnail beside the text:
<meta name="twitter:card" content="summary">Note the name attribute. Twitter Card tags use name, not the property that Open Graph uses.
How X falls back to og:* for title, description, and image
For the title, description, and image, X reads your og:title, og:description, and og:image when the matching twitter:* tag is absent. That is why you rarely write twitter:title or twitter:image at all. Set twitter:card, keep your Open Graph tags clean, and X assembles the card from them.
The empty-twitter:image trap
The fallback has one sharp edge: an empty tag counts as present. If you emit twitter:image with a blank value, X uses that empty value instead of falling back to og:image, and your card loses its picture.
<!-- Wrong: blocks the fallback and leaves the card imageless -->
<meta name="twitter:image" content="">
<!-- Right: omit the tag entirely and X reads og:image -->The rule is simple: never output an empty social tag. Leave it out when you have no value.
Slack and Discord specifics
Slack reads the Twitter Card first, then Open Graph, and it can surface two extra fields through twitter:label and twitter:data:
<meta name="twitter:label1" content="Reading time">
<meta name="twitter:data1" content="11 minutes">
<meta name="twitter:label2" content="Written by">
<meta name="twitter:data2" content="Ada Lovelace">Those show up as small labelled details under a Slack unfurl. Discord reads Open Graph and adds one flourish nobody else uses: it colors the embed’s left accent bar with your page’s theme-color.
<meta name="theme-color" content="#5865F2">How link previews render on each platform
The same tags produce different social media link previews depending on who reads them. Each platform picks its own subset of tags, caches for its own window, and adds a quirk or two. This table is the quick reference.
| Platform | Tags it reads | Cache | Notable behavior |
|---|---|---|---|
| Open Graph | ~30 days | Ignores images under 200×200; shows a small square below 600×315 | |
| Open Graph | ~7 days | Clear a stale preview with the Post Inspector | |
| X (Twitter) | twitter:card + falls back to og:* | short | No twitter:card means no card at all |
| Slack | Twitter Card, then Open Graph | per message | Renders twitter:label/twitter:data as extra fields |
| Discord | Open Graph | per message | Uses theme-color for the embed’s accent bar |
og:title + og:image | per message | Wants metadata near the top; keep the image under 300 KB | |
| Telegram | Open Graph | per message | Renders reliably only from JPEG or PNG |
| Open Graph or Schema.org | — | Article Rich Pins need og:type=article |
The cache column explains a common surprise: you fix your tags, reshare, and Facebook still shows the old title for weeks. Facebook holds Open Graph data for about 30 days and LinkedIn for about 7, so an edit won’t appear until the cache expires or you force a refresh. The debuggers below do exactly that.
Common Open Graph mistakes (and how to catch them)
Most broken previews trace back to a short list of errors. Each one looks fine locally and only fails when a crawler fetches the live page.
Relative og:image path
A relative path renders in your browser and breaks when shared, because the crawler has no base URL to resolve it against.
<!-- Blank when shared -->
<meta property="og:image" content="/cover.png">
<!-- Renders everywhere -->
<meta property="og:image" content="https://example.com/cover.png">Missing og:url or canonical that disagrees with it
Without og:url, share counts and engagement scatter across URL variants (with and without www, with tracking parameters, with a trailing slash). Point both your canonical link and og:url at the same single URL so the signals stay together.
Image too small or the wrong aspect ratio
An image below 200×200 is ignored outright, and one far from 1.91:1 gets cropped in ways you didn’t plan. Ship 1200×630 and the framing is predictable on every platform.
Forgetting twitter:card
A full set of Open Graph tags still produces no card on X without twitter:card. This is the most common reason a link looks great on LinkedIn and shows nothing on X.
Client-side-rendered tags a crawler can’t see
If a single-page app injects Open Graph tags after load, crawlers that don’t run JavaScript never see them. Render the tags server-side or pre-render the HTML.
charset placed after the first 1024 bytes
The <meta charset="utf-8"> declaration has to appear within the first 1024 bytes of the document, or the browser ignores it and can garble non-ASCII characters in your title and description. Put it first inside the <head>:
<head>
<meta charset="utf-8">
<!-- everything else follows -->
</head>How to test and debug your Open Graph tags
Never trust a preview you haven’t verified against a live URL. Three tools cover the platforms that matter, and all of them can force a cache refresh.
Facebook Sharing Debugger
The Facebook Sharing Debugger fetches your live URL, shows exactly what Facebook parsed, and lists any missing or malformed tags. Its most useful button is “Scrape Again,” which refreshes Facebook’s ~30-day cache on demand, the fastest way to make a fix appear without waiting a month.
LinkedIn Post Inspector
The LinkedIn Post Inspector does the same job for LinkedIn. Paste a URL and it re-fetches the page and clears LinkedIn’s ~7-day cache, so an updated title or image shows up on your next share instead of days later.
X card validation moved into the developer portal
X retired its standalone Card Validator. As of 2026, card validation lives inside the X developer portal rather than at a public URL, so most teams verify X cards a different way: because X falls back to og:*, the Facebook and LinkedIn debuggers already confirm the tags X will read, and a third-party preview tool fills the gap for the twitter:card layout itself.
Preview before you deploy
Debuggers can only inspect a URL that’s already live, which is a poor moment to discover a blank image. Preview the card while you’re still editing. The Meta Tag Generator renders Google, Facebook, X, LinkedIn, Slack, and Discord previews from the values you type, reads your og:image’s real dimensions in the browser to catch a wrong ratio, and can import an existing <head> so you can diagnose a broken share before it ships.
Quick checklist
Here is the minimum every page should carry. Copy it, swap in your values, and you have a preview that renders across the board:
<meta charset="utf-8">
<title>Your page title</title>
<meta name="description" content="Your 150-character summary.">
<link rel="canonical" href="https://example.com/page">
<meta property="og:title" content="Your page title">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/page">
<meta property="og:image" content="https://example.com/og/page.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:description" content="Your 150-character summary.">
<meta name="twitter:card" content="summary_large_image">Run through the essentials before you ship: an absolute HTTPS og:image at 1200×630, og:url matching your canonical, twitter:card present, and the tags rendered server-side. If you want a fuller tour of the utilities that speed this up, the developer tools guide collects the rest. When you’re ready to generate and preview the whole block at once, the Meta Tag Generator writes it, checks it, and shows every card before you deploy.
Frequently asked questions
What’s the difference between Open Graph and Twitter Card tags?
Open Graph is a cross-platform protocol read by Facebook, LinkedIn, Slack and more; Twitter Card tags (twitter:*) are X-specific. X falls back to your OG tags when the matching twitter:* tag is missing, so you usually need OG plus a single twitter:card value.
Do Open Graph tags affect Google search rankings?
No. Open Graph and Twitter Card tags don’t influence Google rankings. They control how links look when shared, which is where social traffic comes from. The classic <title> and canonical tags matter for SEO; the meta description shapes your snippet and click-through but isn’t a direct ranking factor.
Where do Open Graph tags go in the HTML?
Inside the <head> element, in the server-rendered or static HTML. Facebook, LinkedIn, WhatsApp and Telegram crawlers don’t execute JavaScript, so tags injected client-side won’t be seen. Put <meta charset> first so it lands within the first 1024 bytes.
Can one image work for Facebook, X and LinkedIn?
Yes. A single 1200×630 (1.91:1) image renders correctly on Facebook, LinkedIn, Slack, Discord and X’s summary_large_image card. Serve it over HTTPS at a public URL and declare og:image:width/og:image:height so the first share isn’t blank.
Why is my link preview showing no image?
Common causes: a relative og:image path instead of an absolute HTTPS URL, an image below 200×200, a missing twitter:card on X, or tags injected by JavaScript the crawler can’t run. Re-scrape with the Facebook Sharing Debugger after fixing.
Do all pages need their own Open Graph tags?
Ideally yes. Each page should have an og:title, og:description, og:image and canonical og:url that reflect that specific page, so shared links show relevant previews. A site-wide fallback is better than nothing, but per-page tags win far more social clicks.