Open Graph tags are the <meta> properties in a page's <head> that tell Facebook, LinkedIn, X, Slack, and WhatsApp what to show when someone shares your link, rather than leaving it to guess. Every object needs four of them: og:title, og:type, og:image, and og:url, as set out in the Open Graph protocol. Miss one and you get a blank box, a random screenshot, or no preview at all.
Here's the minimum you need, copied straight into your page's <head>:
<meta property="og:title" content="Your Page Title" />
<meta property="og:type" content="website" />
<meta property="og:image" content="https://example.com/image.jpg" />
<meta property="og:url" content="https://example.com/page" />
That's it. Four lines, and your link goes from an ugly grey box to a proper preview with a title, image, and clickable card. Before you go any further:
- Test the page with a validator (we'll cover exactly which ones below).
- Confirm the tags appear in your server-rendered HTML, not just after JavaScript runs.
- Check the image loads over HTTPS and isn't blocked by a firewall or CDN rule.
- Use an absolute URL for
og:image, never a relative path like/images/hero.jpg.
If you're short on time and just want this handled properly across every page of your site, skip to the bottom for how Ace-sites builds these in from day one. Otherwise, let's get into the syntax.
Key Takeaways
Open Graph tags control how your links look when shared, and getting the four required properties right in server-rendered HTML fixes most preview problems outright.
Table of Contents
- What are the required open graph meta tags and their syntax?
- Which optional OG properties are worth adding?
- How do you actually add these tags to your site?
- What image sizes and formats work best for OG tags?
- How do you test and debug open graph tags?
- Do you need Twitter Card or Schema.org tags too?
- Why do open graph previews break, and how do you fix them?
- What do copy-paste OG examples look like for different page types?
- Which platforms actually read open graph tags?
- A note on getting this right without a developer on staff
- Want your Open Graph tags handled without touching a line of code?
- Sources
What are the required open graph meta tags and their syntax?
Every OG tag uses the same structure: <meta property="og:PROPERTY" content="VALUE" />. Notice it's property=, not name=. That's deliberate. Open Graph is built on RDFa, a vocabulary system that lets crawlers understand relationships between data, not just read isolated key-value pairs the way standard meta tags do. Get that attribute wrong and some scrapers will silently ignore the tag.
Here's what each required tag actually needs:
og:title— Keep it under 60 characters where you can. Longer titles get truncated by Facebook and LinkedIn, and a chopped-off headline looks sloppy in a feed.og:type— Defaults towebsiteif you're unsure, but usearticle,video.movie, orprofilewhen they genuinely apply (more on this below).og:image— Must be an absolute HTTPS URL. A relative path or an HTTP-only image is one of the most common reasons previews fail to render at all.og:url— This should match your canonical URL exactly. Ifog:urland your<link rel="canonical">disagree, platforms sometimes credit the wrong page with shares and engagement.
One rule that trips up a surprising number of otherwise solid developers: these tags have to be present in the HTML that's returned when a crawler first requests the page. Social crawlers generally don't run JavaScript, so tags injected via useEffect in a React app or added after a client-side render often never get seen at all, as the practical guide from Krumzi points out. If your site is client-rendered, you need server-side rendering (SSR) or static generation (SSG) for the tags to work reliably.
Pro Tip: Always specify og:image:width, og:image:height, and an og:image:alt string alongside your main image tag. It costs you three extra lines of code and it stops crawlers reflowing the layout while they wait to work out the image's dimensions, which speeds up how quickly a preview renders.
Which optional OG properties are worth adding?
The four required tags get you a working preview. The optional ones make it a genuinely good one. None of these are mandatory, but each solves a specific, common problem.
og:description— The supporting line under your title in most previews. Keep it to around 200 characters and write it to match your actual social copy, not your meta description verbatim, since the two serve different audiences.og:site_name— Shows your brand name next to the preview (e.g. "aceSites" appearing under a shared blog post). Small detail, but it builds recognition when your content gets reshared.og:locale— Tells platforms which language and region the content targets, formatted likeen_GBorfr_FR. If you run a multi-language site, addog:locale:alternatefor each additional version so the right preview shows to the right audience.og:image:alt— Often skipped, always worth including. Screen readers and accessibility tools use this to describe the image to users who can't see the preview, and it's genuinely one of the cheapest wins on this whole list.og:determiner— Rarely used, but it controls the grammatical article ("a", "an", "the") some platforms insert before your title in certain sentence constructions. Most sites can safely ignore it.
If you're running a site with English and French versions of the same product page, og:locale plus og:locale:alternate is the difference between a French visitor getting an English-language card and getting the correct one. Small tag, real consequence.
Structured sub-properties for images, video and audio
Beyond the basic og:image tag, Open Graph supports structured sub-properties that describe the asset in more detail. These matter more than they look like they should.
| Property | What it does |
|---|---|
og:image:url | Explicit image URL (same as og:image, used when you need multiple images) |
og:image:secure_url | HTTPS-specific version of the image URL |
og:image:width / og:image:height | Pixel dimensions, declared upfront |
og:image:type | MIME type, e.g. image/jpeg or image/webp |
og:image:alt | Accessibility description of the image |
og:video:url / og:video:secure_url | Location of a video asset for video-type pages |
og:video:width / og:video:height | Video dimensions |
og:video:type | MIME type, e.g. video/mp4 |
og:audio:url | Location of an audio asset |
og:audio:type | MIME type, e.g. audio/mpeg |
Declaring og:image:width and og:image:height isn't cosmetic. It lets the crawler render the preview immediately using the dimensions you've supplied, instead of downloading the file first to work them out, which is one of the more useful implementation details in the Env. Sites without these two lines routinely show a delayed or broken preview in the split second after a link gets pasted into a chat.
Here's a page with multiple images, which the PreviewOG reference guide confirms is valid, with the first tag treated as primary:
<meta property="og:image" content="https://example.com/main.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:alt" content="Product shot of the blue widget" />
<meta property="og:image" content="https://example.com/alt-angle.jpg" />
Recommendation: stick to JPEG or WebP, keep each file under 300KB where you can, and always serve images over HTTPS. A mismatched MIME type or an image sitting behind a redirect chain is a common, avoidable reason previews quietly fail.
Which og:type value should you use?
og:type isn't just a label. Choosing the right one unlocks extra properties that make your preview richer.
website— The safe default for homepages, service pages, and most static content.article— Use for blog posts and news content. Unlocksarticle:published_time,article:modified_time, andarticle:author.video.movie— For dedicated video pages. Pairs withvideo:durationand theog:video:*sub-properties above.profile— For personal or team member pages. Unlocksprofile:first_nameandprofile:last_name.book— Part of a separate namespace withbook:isbnandbook:author, useful for publishers and authors' sites.
For a blog post, this is a realistic full block:
<meta property="og:type" content="article" />
<meta property="article:published_time" content="2026-02-14T09:00:00+00:00" />
<meta property="article:author" content="https://example.com/authors/gabbi" />
Use article rather than the generic website default whenever the page has a clear publish date and author, because platforms that support rich article previews will surface that extra context automatically.
How do you actually add these tags to your site?
For a static HTML site, you paste the tags directly inside <head>, above the closing tag, and you're done. No build step, no dependencies.
For anything dynamic, the process looks different depending on your setup:
- Templated sites (WordPress, Shopify, Webflow): Use a plugin rather than hand-coding. Yoast SEO and Rank Math both generate OG tags automatically from your title, featured image, and excerpt, and let you override each field per page. The common pitfall is leaving the default fallback image in place across hundreds of posts, which means every shared link looks identical.
- Server-rendered frameworks (Next.js, Nuxt, Astro): Set OG tags in your server-side
<Head>component or metadata export, never in a client-onlyuseEffect. If you're using SSG, generate the tags at build time per page so every URL gets its own unique title and image. - Custom CMS or headless setups: Build the OG block into your page template so it pulls from the same content fields your page already uses, title, hero image, summary, rather than maintaining a separate OG dataset that drifts out of sync.
Whichever route you take, the non-negotiable checklist stays the same: canonical og:url matching your actual canonical tag, a per-page image rather than one site-wide default, and dimensions set on the server before the HTML ships. Ace-sites builds pages this way by default, which is worth knowing if you'd rather not manage a plugin update cycle yourself.
What image sizes and formats work best for OG tags?
The safe default across nearly every platform is a 1200×630 pixel image at a 1.91:1 aspect ratio, a figure both env.dev and PreviewOG converge on. It's not a hard rule everywhere, but it's the size that renders cleanly on the most platforms without cropping awkwardly.
A short do-not-do list, because most preview failures trace back to one of these:
- Don't inject OG tags with client-side JavaScript. Crawlers that don't execute JS simply won't see them.
- Don't use relative image URLs (
/img/hero.jpg). Always write the fullhttps://path. - Don't reuse the same generic image across hundreds of pages if you want each link to look distinct in a feed.
- Don't skip
og:image:alteven when the image seems self-explanatory to you.
If your audience skews toward a specific platform, like Pinterest, which favours taller images, it's usually better to add a second image tailored to that ratio rather than trying to force one file to satisfy every network, an approach PreviewOG recommends over a one-size-fits-all image.
Platform caching adds another wrinkle. Once a crawler has fetched your OG data, it holds onto it, which is great for performance but means an updated image or title won't show up instantly the next time someone shares your link.
| Platform | Typical cache window | Image size notes |
|---|---|---|
| Roughly 24 to 72 hours | Re-crawls periodically; force refresh via Sharing Debugger | |
| Around seven days | Slower to re-crawl; Post Inspector forces an update | |
| Varies, tends to cache aggressively on mobile | Stricter file-size budget on mobile connections |
Pro Tip: If you've updated an image and the old one keeps showing, append a version query string to the URL, like ?v=2, rather than just replacing the file at the same path. It's a simple trick that forces most platforms to treat it as a new asset and re-fetch it.
How do you test and debug open graph tags?
Never assume your tags work just because they're in the code. Test them, every time, with a real validator rather than eyeballing the source.
- Meta Sharing Debugger — Paste in your URL and it shows exactly what Facebook's crawler sees, plus a button to force a re-scrape after you've made changes.
- X Card Validator — Confirms whether your card renders as summary or large-image, and flags missing or malformed tags.
- LinkedIn Post Inspector — LinkedIn caches aggressively, so this tool is often the only way to force it to pick up a genuinely new title or image.
Beyond the official tools, a quick manual check with curl tells you what's actually being served, stripped of any client-side rendering that might be masking a problem:
curl -s https://example.com/page | grep 'og:'
If that command returns nothing, your OG tags aren't in the server-rendered HTML, full stop. That's the single most common cause of a broken preview, and it's worth checking before you touch anything else.
A short debug checklist worth running through in order:
- Fetch the raw HTML (via
curlor "view source", not dev tools inspector) and confirm the tags are present. - Check the image URL loads directly in a browser tab, over HTTPS, with no redirect.
- Confirm your server isn't returning a 3xx redirect on the page itself, which some crawlers won't follow.
- Re-scrape with the relevant platform debugger after every change, since caching means your fix won't show up on its own.
Do you need Twitter Card or Schema.org tags too?
Open Graph doesn't operate alone. X (formerly Twitter) reads its own twitter:* tags first and only falls back to og:* values when they're absent, so many sites add a single line to opt into the large image card format while reusing their existing Open Graph data for everything else:
<meta name="twitter:card" content="summary_large_image" />
Notice that one uses name=, not property=. Twitter Cards were built on a slightly different spec to Open Graph, which is why the attribute changes even though the tags sit right next to each other in your <head>.
Most platforms, though, including LinkedIn, Slack, Discord, and WhatsApp, default to reading Open Graph tags directly when no platform-specific alternative exists, according to the Open Graph protocol glossary. That's what makes OG the practical baseline: add it once, and you've covered the majority of platforms your links will land on.
Schema.org and JSON-LD serve an entirely different purpose. They're aimed at search engines, not social crawlers, and they influence how your page might appear as a rich result in Google, not how it looks when pasted into a Slack channel. Add JSON-LD when you want structured search snippets; add Open Graph when you want a clean social preview. Most content sites eventually need both, but they're solving different problems and neither one substitutes for the other.
Why do open graph previews break, and how do you fix them?
Most OG failures fall into a short, predictable list. Here's what usually causes each symptom.
- Blank preview or no image at all — Almost always JavaScript-injected tags that the crawler never saw. Fix: move the tags into your server-rendered HTML.
- Wrong or old image showing — Either a relative URL that resolved incorrectly, or the platform's cache serving stale data. Fix: use absolute HTTPS URLs and force a re-scrape.
- Preview stuck on an outdated title — Classic caching. Fix: use the relevant debugger tool to force a re-crawl rather than waiting it out.
- Image showing tiny or cropped oddly — The file is below the platform's minimum size threshold. Fix: use 1200×630 as your baseline.
Beyond those, check for blocked resources. If your image sits behind a CORS restriction, a security header like X-Frame-Options, or a redirect chain longer than a couple of hops, some crawlers give up before they ever render it. Server logs are the fastest way to confirm whether the crawler's request for your image actually succeeded or got refused.
Finally, check robots.txt. If it blocks the crawler's user agent from accessing your image directory or the page itself, no amount of correct OG syntax will help, because the crawler never gets far enough to read the tags in the first place.
What do copy-paste OG examples look like for different page types?
Article page:
<meta property="og:title" content="How to Fix Broken Link Previews" />
<meta property="og:type" content="article" />
<meta property="og:image" content="https://example.com/blog/hero.jpg" />
<meta property="og:url" content="https://example.com/blog/broken-previews" />
<meta property="article:published_time" content="2026-01-10T08:00:00+00:00" />
<meta property="article:author" content="https://example.com/authors/gabbi" />
Product page:
<meta property="og:title" content="Blue Widget - Handmade, Ships Free" />
<meta property="og:type" content="website" />
<meta property="og:image" content="https://example.com/products/blue-widget.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:url" content="https://example.com/products/blue-widget" />
<meta property="og:description" content="Handmade blue widget, ships free within the UK." />
Video page:
<meta property="og:title" content="Watch: Setting Up OG Tags in Five Minutes" />
<meta property="og:type" content="video.movie" />
<meta property="og:image" content="https://example.com/videos/thumb.jpg" />
<meta property="og:video" content="https://example.com/videos/setup.mp4" />
<meta property="og:video:type" content="video/mp4" />
<meta property="video:duration" content="312" />
<meta property="og:url" content="https://example.com/videos/setup" />
Notice the product example sticks with website rather than a dedicated product type. Open Graph's official spec doesn't define a universal product namespace the way it does for articles, so most product pages are best served by rich, accurate og:title and og:description values rather than chasing a non-standard type. For any of these, swap the static values for template variables pulling from your CMS fields, title, hero image, and publish date, so each page generates its own unique tags automatically.
Which platforms actually read open graph tags?
Facebook created the Open Graph protocol, but its reach now extends far past Meta's own products. LinkedIn, X (as a fallback), Slack, Discord, WhatsApp, iMessage, and Telegram all read OG data by default when no platform-specific tag exists, which is exactly what makes it worth implementing properly in the first place, according to the Open Graph protocol glossary.
Each platform has its own quirks worth knowing before you assume "it works everywhere the same way":
- Facebook re-crawls roughly every 24 to 72 hours, and its Sharing Debugger is the fastest way to force an earlier refresh.
- LinkedIn caches for closer to seven days, which catches out marketers who update a campaign image and can't work out why the old one still shows.
- WhatsApp, particularly on mobile connections, applies a stricter file-size budget than desktop platforms, so an oversized image that looks fine on Facebook may fail to load in a WhatsApp preview.
- Slack and Discord tend to re-fetch more readily, useful for internal links that change often.
Worth knowing too: AI chat tools and link-unfurling features in messaging apps increasingly read the same Open Graph metadata to generate their own previews and summaries. The tags you write for Facebook are doing double duty as the metadata layer for a growing number of AI-driven interfaces, which is one more reason to get them right once rather than patch them later.
A note on getting this right without a developer on staff
Most of the failures covered in this guide come down to the same root cause: tags added without checking whether they actually render in the HTML a crawler receives. If you're a small business owner managing your own site, that's worth treating as your single priority. Get the four required tags right, use a real 1200×630 image per page rather than one generic logo everywhere, and confirm the tags are server-rendered, not appended by a script after the page loads.
DIY makes sense when you're running a handful of pages and you're comfortable checking your work in a validator. It stops making sense once you're managing dozens of pages, running seasonal promotions that need fresh images regularly, or relying on a CMS plugin that quietly reverts to a default image whenever you forget to set one manually. At that point, a delivered service that builds OG handling into the platform itself saves you from re-learning this guide every few months.
None of this is guesswork once you understand the four required tags and how caching works against you. The gap is almost always implementation discipline, not technical difficulty.
Want your Open Graph tags handled without touching a line of code?
Ace-sites is the alternative to hiring a developer for this: every site built on the platform ships with server-rendered pages and built-in SEO tools, which means your og:title, og:image, and og:url tags go live correctly on day one, not after a round of manual fixes.
The done-for-you build service covers the parts that trip up most small business owners: unique per-page images sized correctly, tags rendered server-side so crawlers actually see them, and testing against the platform validators covered above before your site goes live. That's different from a plugin bolted onto a template you're still managing yourself, since the tags are part of how the page gets built in the first place, not an afterthought you configure separately.
If you'd rather see it in action first, browse the portfolio of real business sites built this way, then get your own free build started, and pay nothing until you've seen the finished result.
Sources
A handful of pages are worth keeping open in a tab whenever you're troubleshooting a stubborn preview.
- Ogp
- Env
- Open Graph tags: the complete reference guide — PreviewOG
- Getstream
- How to write OG meta tags: a practical guide — Krumzi