What Are Open Graph Meta Tags?
When you paste a link into Twitter, Facebook, LinkedIn, Slack, Discord, or iMessage, the rich preview card — title, description, big image — does not come from magic. It comes from meta tags in your page's <head>. The dominant standard is the Open Graph protocol, created by Facebook in 2010: tags like <meta property="og:title" content="..."> that describe your page in a structured way any crawler can read. Twitter then built its own Twitter Card tags (twitter:card, twitter:image) on top of the same idea, falling back to Open Graph values when its own tags are missing.
Without these tags, platforms guess — usually badly. They grab the <title>, the first paragraph of text, and some random image (often a favicon or an ad banner). With them, you control exactly what millions of people see when your link travels. For content sites, the preview card is frequently the actual first impression; the click happens only if the card earns it. Studies of social click-through consistently show that posts with complete, attractive cards outperform bare links by wide margins.
The Essential Tags
You need surprisingly few tags to cover nearly every platform:
- og:title — the card headline. Keep it under ~60 characters so it is not truncated. This tool's core function builds exactly this tag:
ogTitle('Hello')→<meta property="og:title" content="Hello">. - og:description — one or two sentences, 50–160 characters. It should work as a standalone pitch for someone who has never heard of you.
- og:image — absolute URL to the preview image. The single highest-impact tag on the page.
- og:url — the canonical URL of the page. Prevents duplicate cards for URL variants (with/without trailing slash, UTM parameters).
- og:type — usually
website; usearticlefor blog posts (which unlocksarticle:published_timeand author tags). - twitter:card — set to
summary_large_imagefor the big-image layout. Without it, Twitter may render the small thumbnail card.
That is the 90% solution. Everything else — og:site_name, og:locale, image dimensions — is refinement.
The Image: 1200 × 630 or Bust
The recommended Open Graph image size is 1200 × 630 pixels (a 1.91:1 aspect ratio). This is not arbitrary: it is the size Facebook's crawler requests, and every other platform degrades gracefully from it. The minimums that still work are 600 × 315 (below this, Facebook may refuse to render a large card) and 300 × 200 for LinkedIn's fallback. Keep the file under ~1MB — crawlers time out on slow images — and prefer JPG for photos, PNG for graphics with text.
Design for the safe zone: keep text and logos inside the central ~1000 × 520 region. Different platforms crop differently — Twitter's mobile app, LinkedIn's feed, and Slack's unfurl each shave the edges slightly differently. The classic failure is a beautiful card where the headline text gets cropped on mobile. This tool's image validator loads your image URL and reports the actual dimensions, so you catch a 400 × 400 square or a 3MB monster before you ship.
| Platform | Card size | Notes |
|---|---|---|
| 1200 × 630 | Defines the standard; crops to 1.91:1 | |
| Twitter / X (large) | 1200 × 628 (2:1) | Needs twitter:card = summary_large_image |
| 1200 × 627 | Falls back gracefully from 1.91:1 | |
| Slack / Discord | ~1200 × 630 | Unfurls from og: tags; Discord needs the image publicly reachable |
| iMessage / WhatsApp | ~1200 × 630 | WhatsApp caches aggressively — test with fresh URLs |
Absolute URLs: The Number-One Bug
The most common Open Graph failure is a relative image URL: content="/images/card.jpg". It works in your browser, and it fails everywhere else, because the crawler fetching your page has no base URL context the way a browser does (technically it does, but many crawlers resolve relative og:image URLs inconsistently — Facebook historically mishandled them). Always use the full https://yoursite.com/images/card.jpg. Same for og:url. This tool generates absolute-URL-first output and the checklist flags relative URLs.
Caching: Why Your Fixed Card Still Looks Broken
You fixed the tags, reposted the link, and the old broken card is still there. This is crawler caching, and it surprises everyone once. Facebook caches link previews for days; WhatsApp caches nearly forever per URL; Twitter's card validator can force a refresh. The remedies:
- Facebook: run the URL through the Sharing Debugger and click 'Scrape Again.'
- Twitter/X: use the Card Validator to refresh the cache.
- LinkedIn: the Post Inspector refreshes their cache.
- WhatsApp: append a cache-busting query string (
?v=2) — it treats it as a new URL. Crude but effective. - Slack: unfurls refresh on a schedule; re-posting usually picks up changes within hours.
Pro tip: version your og:image filename (card-v2.jpg) instead of overwriting — new filename, new cache entry, zero waiting.
Twitter Cards vs Open Graph
Twitter reads Open Graph tags as fallback, so a page with only og: tags still gets a decent Twitter card. But two Twitter-specific tags are worth setting explicitly. twitter:card with summary_large_image forces the big-image layout (the default without it is the small thumbnail, which wastes your 1200 × 630 image). twitter:creator (your @handle) adds attribution. Everything else — title, description, image — Twitter happily takes from your og: tags. One subtlety: Twitter's crawler requires the image to be publicly accessible without login and under 5MB, and it is pickier about SSL validity than Facebook's.
Dynamic Pages and Framework Gotchas
Social crawlers mostly do not run JavaScript. If your meta tags are injected client-side by React/Vue after load, crawlers see an empty head and your cards break. The fixes, in order of preference: server-side rendering (Next.js, Nuxt, or any SSR), static generation with per-page tags baked in at build time, or a prerendering service that serves crawler user-agents a rendered snapshot. For SPAs, the pragmatic minimum is SSR (or at least pre-rendering) for the pages people actually share — usually article, product, and landing pages.
The Validator Checklist, Explained
This tool's checklist encodes what experienced developers verify before shipping:
- Title present and ≤ 60 chars — longer titles get truncated mid-word on most platforms.
- Description 50–160 chars — shorter looks empty, longer gets cut.
- Image absolute URL, ≥ 600 × 315 — relative URLs and tiny images are the two classic failures.
- twitter:card set — without it you risk the small-thumbnail layout.
- og:url canonical — consolidates share counts and prevents duplicate cards.
- No JavaScript dependency — tags must be in the raw HTML the crawler fetches.
Beyond the Basics: Article Tags and Rich Objects
For publishers, og:type=article unlocks article:published_time, article:author, and article:section — used by news aggregators and Facebook's article ranking. E-commerce sites can use og:type=product with price tags (support varies). Video pages get og:video for inline playback in feeds. And og:locale plus og:locale:alternate help multilingual sites serve the right card per region. None of these replace the core six tags — they are the second coat of paint.
Measuring Card Performance
Once your cards are live, treat them like any other conversion surface. UTM parameters on shared links (kept out of og:url so the canonical stays clean) let analytics attribute traffic to social shares. A/B test card images the way you would ad creative — the image is typically 70%+ of the card's visual weight, and swapping a generic stock photo for a specific, high-contrast image with minimal text routinely moves click-through. The preview in this tool shows you what the platforms will show; the checklist makes sure the machinery underneath is sound.
Open Graph for E-commerce and Video
Product pages deserve richer cards than the basics. The og:type=product object supports price and availability tags (product:price:amount, product:price:currency, product:availability), which some platforms render as price badges directly on the card — a meaningful click-through lever for retail. Video pages can use og:video (with og:video:width, og:video:height, and og:video:type) to enable inline playback in feeds on platforms that support it; a playable card dramatically outperforms a static one for video content. Podcasts and music get og:audio similarly. The pattern is consistent: the more structured data you provide, the richer the platform's rendering — but only the core six tags are universally supported, so treat the rest as progressive enhancement.
E-commerce has one extra trap: variant URLs. A product with color/size variants often has a URL per variant, and without a canonical og:url each variant generates its own card — fragmenting share counts and showing the wrong variant image in shares. Point every variant's og:url at the canonical product URL and pick the hero image deliberately.
International and Multi-Region Cards
Global sites need per-locale cards. The og:locale tag declares the page's language-region (e.g., en_US), and og:locale:alternate lists the other available locales — crawlers use these to pick the right card for the viewer's region. In practice, most teams implement this by rendering locale-specific tag sets server-side per URL path (/en/… vs /fr/…), with translated titles and descriptions and sometimes locale-appropriate imagery. Test each locale's URL separately in the platform debuggers; a French user seeing the English card is a silent conversion killer. Right-to-left locales deserve a design check too — card layouts mirror, and text baked into images will not.
When Cards Break: A Troubleshooting Guide
- No image renders: check the URL is absolute, publicly reachable (no login wall, no hotlink protection blocking the crawler), and under size limits. Test with curl from an external server.
- Wrong image: another
og:imagetag earlier in the head wins, or the crawler cached an old one — scrape again / version the filename. - Card shows but title is wrong: duplicate
og:titletags, or the crawler read a JavaScript-rendered page before hydration — check raw HTML. - Works on Facebook, not Twitter: missing
twitter:card, or Twitter's crawler is blocked by robots.txt (it obeys it; Facebook's is more lenient). - Works everywhere except WhatsApp: WhatsApp caches per URL aggressively and needs the image under ~300KB for reliable rendering — compress and version the URL.
- Intermittent failures: slow image hosting — crawlers time out. Move og images to a CDN with fast global TTFB.