Open Graph meta tags are small HTML tags that tell Facebook, LinkedIn, Slack, and X how to display your link when someone shares it. By the end of this guide you'll know every tag that matters, the exact size your og:image should be, and how to test the whole thing before you ship.
The short version: add og:title, og:type, og:url, and og:image to your page's <head>, make the image 1200 by 630 pixels, and validate it in a debugger before you trust it. The rest of this post is the why, the full tag list, and the edge cases that bite in production.
What are Open Graph meta tags?
Open Graph meta tags are <meta> tags in the <head> of a page that describe the page to social platforms and chat apps. They come from the Open Graph protocol, which Facebook published in 2010 and which LinkedIn, Slack, Discord, WhatsApp, and X all read today. Each tag uses a property attribute and a content attribute, which is the one quirk that trips people up: most meta tags use name, but Open Graph uses property.
Without these tags, a shared link falls back to whatever the platform can scrape: often a truncated title, no description, and a blank gray box where the image should be. With them, you control the headline, the summary, and the preview image. Four of the tags are images or text you write once, but one of them, og:image, is an actual image per page, which is why it is the tag most teams end up automating with a tool like ScreenshotRender. More on that under image sizing.
Which Open Graph meta tags are required?
The Open Graph protocol marks four properties as required: og:title, og:type, og:image, and og:url. Set these four and every major platform can render a complete card. Here is the minimum block, ready to paste into your <head>:
<meta property="og:title" content="Open Graph Meta Tags Guide"><meta property="og:type" content="article"><meta property="og:image" content="https://screenshotrender.com/blog/og.png"><meta property="og:url" content="https://screenshotrender.com/blog/open-graph-meta-tags">
In practice you'll almost always add og:description too, because a card without a summary looks half finished. The protocol calls it optional, but every team that cares about share rates treats it as required in everything but name.
What does each Open Graph meta tag do?
Each Open Graph tag controls one part of the share card, and a few unlock extra behavior. Here is what every tag you'll realistically use actually does.
og:title
og:title sets the bold headline of the card. Keep it under about 60 characters so it does not truncate, and write it for a human reading a feed rather than for a search engine. Example: <meta property="og:title" content="How to Screenshot a Cloudflare Site">.
og:type
og:type tells platforms what kind of object the page is, and the value changes which extra tags are valid. Use website for a home or landing page and article for blog posts and news. The protocol also defines namespaced types such as profile, book, music, and video, each with their own properties. The full list lives in the Open Graph types reference.
og:url
og:url is the canonical URL for the object. It should be the clean, permanent address of the page, without tracking parameters, so that shares of ?utm_source=twitter and the bare URL get treated as the same object. Make it absolute and use https.
og:image
og:image is the preview image, and it carries most of the visual weight of the card. It must be an absolute URL, and the image itself should be 1200 by 630 pixels (see the next section for why). This is the one tag that is genuinely hard to maintain by hand, because every page wants its own image. You can design each one in Figma, build a rendering pipeline with Puppeteer or Satori, or turn any URL or HTML template into an image with a single API call. We cover the automation path in depth in automating Open Graph images at scale.
og:description
og:description is the one or two line summary under the title. Aim for 110 to 160 characters: long enough to add context, short enough that no platform truncates it. It does not have to match your meta description, and a sharper, more conversational line often outperforms the search-tuned version.
og:site_name
og:site_name is the name of the overall site, like "ScreenshotRender" or "The Guardian", shown as a small label on the card. It is optional but cheap to add and it reinforces your brand on every share.
What size should an Open Graph image be?
An Open Graph image should be 1200 by 630 pixels, which is the size Facebook recommends and a 1.91 to 1 aspect ratio that every other platform crops cleanly. Go smaller than 600 by 315 and platforms downgrade you to a tiny square thumbnail instead of the large card. Keep the file under 8 MB, use PNG or JPEG, and remember that the image URL has to be absolute and publicly reachable, because the platform's crawler fetches it server side.
The trap is consistency. One hand-made image looks great; 200 blog posts each needing their own on-brand 1200 by 630 image is a content pipeline. This is where generating the image from the page itself wins: with ScreenshotRender the entire job is one request: https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://github.com. You get back a hosted image URL you can drop straight into og:image, at the default 1280 by 720 viewport that maps close to the social ratio. Cookie banners, ad overlays, and chat widgets are stripped before the capture, so the preview is the page, not the page plus three popups.
Stop hand-designing an og:image for every page.
Design a 1200 by 630 Open Graph image right in your browser with our free generator: add a title, theme, and logo, preview the live social card, then download the PNG. No sign up, no design tool, and the API renders one from a URL when you need hundreds.
Generate an OG imageHow do you add Open Graph tags to a web page?
You add Open Graph tags by placing the <meta> tags inside the <head> element of the page, before the closing </head>. On a static site or a server-rendered template that is a literal copy and paste. The only rule that matters is that the tags are present in the HTML the crawler receives, which is why a purely client-rendered single page app often ships empty cards: the bot reads the initial HTML before your JavaScript runs.
On a modern framework you set them in code rather than by hand. In Next.js you return an openGraph object from the Metadata API, and the framework renders the tags server side for you, which sidesteps the empty-card problem entirely. Whatever the stack, the destination is the same: real <meta property="og:..."> tags in the served HTML.
How do you test your Open Graph meta tags?
You test Open Graph tags by running the URL through each platform's own debugger, because that shows the exact card the platform will build, not a guess. Three are worth keeping bookmarked:
- Facebook Sharing Debugger shows what Facebook scraped and lets you force a re-scrape with Scrape Again.
- LinkedIn Post Inspector does the same for LinkedIn, which caches aggressively.
- Our own Open Graph preview tool renders the card for every major platform at once, so you can eyeball all of them before you publish.
If you are still building the image side, the free Open Graph image generator produces a correctly sized 1200 by 630 image you can wire straight into og:image while you test.
Why are my Open Graph tags not working?
Most broken Open Graph cards come down to four causes, and the fix is rarely the tag syntax itself.
- Stale cache. Platforms cache the first card they build, so edits do not show until you force a re-scrape in the Sharing Debugger or Post Inspector. This is the single most common "it's not updating" complaint.
- Relative image URLs. A
og:imageof/og.pngfails because the crawler has no base URL to resolve it against. Always use the absolutehttps://address. - Client-side rendering. If the tags are injected by JavaScript after load, the crawler never sees them. Render the tags server side or pre-render the page.
- Login walls and blocked bots. If the page sits behind authentication, or the crawler is blocked, there is nothing to scrape. A preview of a protected page has to come from a render that can reach it, which is where a service that handles the fetch for you earns its keep.
Work down that list before you touch the markup. Nine times out of ten the tags were fine and the card was cached, relative, or invisible to the bot.
Common questions about Open Graph meta tags
What is the difference between og:title and the title tag?
The HTML <title> tag sets the browser tab text and the clickable headline in Google search results. og:title sets the headline shown when the page is shared on Facebook, LinkedIn, Slack, or X. They often hold the same text, but you can split them: a longer, keyword-led title tag for search and a punchier og:title for the feed. If you omit og:title, most platforms fall back to the title tag.
Do Open Graph tags help SEO?
Not directly. Google does not use Open Graph tags as a ranking factor. They help indirectly by controlling how your link looks when it is shared, which lifts click-through rate and the social signals that follow from more people clicking and sharing. Treat them as a sharing and conversion tool, not a ranking tag.
What values can og:type have?
The protocol defines a fixed set. The most common is website, the right default for a home or landing page. Use article for blog posts and news, which unlocks extra properties like article:published_time and article:author. There are also namespaced types for richer objects: profile, book, music, and video. If you do not set og:type, platforms treat the page as a website.
Why is my Open Graph image not updating on Facebook or LinkedIn?
Both platforms cache the first version of a card they see, so a new og:image can keep showing the old one. Force a refresh by pasting the URL into the Facebook Sharing Debugger and clicking Scrape Again, or into the LinkedIn Post Inspector. Also confirm the og:image is an absolute URL starting with https, since relative paths are a common reason the image never loads at all.
Do I need Twitter Card tags if I already have Open Graph tags?
Mostly no. X reads Open Graph tags as a fallback, so a page with og:title, og:description, and og:image already renders a card. Add twitter:card set to summary_large_image when you want the big image layout, and twitter:site to attribute the post to an account. Everything else can come from your existing Open Graph tags.
The honest takeaway: four tags do the real work, og:image does the heaviest lifting, and a debugger settles every argument about whether a card is broken. Get the title, type, url, and image right, render them server side, and validate once. After that the only ongoing cost is producing a fresh image per page, and that is the part worth automating.
