Open Graph Tags: 2026 Guide to Link Previews
For example, a Berlin design studio shares its newest case study on LinkedIn, and the card that appears is a letdown. Instead of the project photo, it shows the cookie consent headline from the top of the page and a tiny logo. A colleague reposts the link on Facebook, and that card has no image at all.
Neither platform is at fault here. Both read a handful of Open Graph tags from the page itself, so the fix lives in your page's code, not in the post. When those tags are missing, Meta says its crawler makes "a best guess" about the title, description and image, and a cookie banner is an easy wrong guess.
This guide helps anyone who publishes pages that get shared, whether you run a coffee roaster in Seattle, a studio in Germany or a skincare brand in South Korea. It covers what the protocol requires, the image sizes each platform documents, why an old preview lingers, and how X and Google use the same data.
What are Open Graph tags, and where did they come from?
Open Graph tags are meta tags in the head of a web page that tell sharing platforms which title, image, description and URL to show. The spec at ogp.me says the protocol lets any web page become a rich object in a social graph. It was created at Facebook, and LinkedIn and X both document how they use it.
The spec says it is based on RDFa and that you add meta tags to the head of your page. It also says the protocol "was originally created at Facebook" and its spec is available under the Open Web Foundation Agreement, Version 0.9. I think it is the closest thing the web has to a shared preview standard, so read the Open Graph protocol specification once, start to finish.
Which four properties does every page need?
The spec names four required properties for every page: og:title, og:type, og:image and og:url. Together they give each platform a title, a type, a picture and a stable address for the page you want shared. Leave one out and the platform has less to work with, and in my view that is how most odd previews start.
The spec's own example is the IMDb page for The Rock, with og:type set to video.movie. Meta says likes and shares for the og:url address aggregate there, so in my reading a messy og:url splits them. My advice is to make og:url match the canonical URL you already chose, and our guide to canonical tags and how Google picks one URL among duplicates explains that choice.
How should you write og:title and og:description?
Write og:title as the plain title of the page, and Meta asks you to leave out branding such as your site name. Keep og:description to about two sentences that say what the reader gets. X's Cards markup reference lists a 70 character limit for titles and a 200 character limit for descriptions, a handy ceiling.
The sources disagree on length, since the spec describes og:description as "A one to two sentence description of your object" while Meta's Webmasters guide says "usually between 2 and 4 sentences". My advice is to write two sentences, because two satisfies both pages and still fits a small card. Our guide to how long title tags and meta descriptions should be also lists character limits for social posts.
What makes a good og:image, and what size should it be?
A good og:image is an absolute URL to a picture made for this page, with its width, height and alt text set in their own tags. Meta advises at least 1080 pixels wide, LinkedIn asks for at least 1200 by 627 pixels, and X's large card supports a 2:1 ratio. X also warns against a generic image such as your site logo.
The spec says a page with og:image should also set og:image:alt, and Meta says width and height tags let its crawler render the image right away. Our guide to optimizing images for the web without losing quality covers compression and file formats.
Every cell comes from the platform's own documentation, saved on October 2, 2026.
| Platform | Tags it reads | Image guidance | Source |
|---|---|---|---|
| Open Graph protocol | og:title, og:type, og:image and og:url required, with og:description and og:site_name optional | An image URL that represents the page, plus og:image:alt | ogp.me specification |
| og:url, og:title, og:description and og:image as basic tags, plus og:type and og:locale | At least 1080 pixels wide, with og:image:width and og:image:height set | Meta for Developers, Webmasters and Best Practices pages | |
| og:title, og:image, og:description and og:url must exist | 5 MB maximum, 1200 x 627 pixels minimum, 1.91:1 recommended, under 401 pixels wide shows as a thumbnail | LinkedIn Help, Make your website shareable on LinkedIn | |
| X summary card with large image | Requires twitter:card set to summary_large_image, plus twitter:title | 2:1 ratio, 300x157 minimum, 4096x4096 maximum, under 5MB, no generic logo | X Developer Platform, Summary Card with Large Image (Internet Archive copy) |
| X fallback | twitter:title, twitter:description, twitter:image and twitter:image:alt fall back to the matching og tags | JPG, PNG, WEBP or GIF (first frame only), no SVG, under 5MB | X Cards markup reference (Internet Archive copy) |
| Google Search | og:title for title links, og:site_name for site names | No image guidance on these pages | Google Search Central, title link and site name pages |
My own arithmetic: 1200 by 627 or 628 pixels is about 1.91:1, meets the LinkedIn minimum and clears the 1080 pixel width Meta advises. X's large card supports 2:1, so in my reading X will likely crop the top and bottom. Keep faces and text near the center.
How does Facebook read your Open Graph tags?
The Facebook Crawler, whose user agent is facebookexternalhit, fetches your page and reads the og tags in its head. If the tags are missing, Meta says the crawler makes a best guess about the title, description and image. The Sharing Debugger shows you which tags it scraped, along with any errors or warnings it found.
Meta's Webmasters sharing guide on Meta for Developers adds a server rule that is easy to miss: your server "must also use the gzip and deflate encodings" so pages share correctly. The same guide says the debugger "also triggers a scrape of your page" so it refreshes as well as tests. My advice is to run it on every new template at least, since one template sets the tags for many pages.
Why does the old preview keep showing after you fix it?
Facebook stores what it scraped, so a fix on your page does not show up there at once. Meta's Best Practices page mentions a standard 24 hour update period and says the Sharing Debugger refreshes scraped content when you need it sooner. Images are a special case, because Meta caches them by URL and keeps the old one until the URL changes.
For example, a Seattle coffee roaster swaps its holiday banner but saves the new art under the old file name. Its Open Graph tags are fine, yet Facebook keeps the old banner, because Meta says a cached image "won't be updated unless the URL changes". The fix: give the new image a new file name, then run the page through the Sharing Debugger so Meta scrapes it again. Meta's Best Practices page also says to pre-cache images by running the URL through the debugger.
What does LinkedIn need before it shows your image?
LinkedIn's help page says your page must follow the Open Graph protocol and lists og:title, og:image, og:description and og:url as the tags that must exist. Its image rules are a 5 MB maximum, at least 1200 by 627 pixels, and a recommended 1.91:1 ratio. LinkedIn adds that images under 401 pixels wide show as a thumbnail.
If the image meets those rules and still fails, the LinkedIn help article on making your website shareable says your site may be blocking it. My reading is that a crawler that cannot fetch your page cannot read its Open Graph tags, and our guide to robots.txt, meta robots and noindex rules shows where blocks live. In my view, blanket bot blocking can also catch crawlers you wanted, a risk our post on whether to block AI crawlers such as GPTBot covers.
Do X cards need their own tags if Open Graph is in place?
Mostly no, because X reads Open Graph as a backup. X's Cards markup reference, saved by the Internet Archive in January 2026, says twitter:title, twitter:description, twitter:image and twitter:image:alt fall back to og:title, og:description, og:image and og:image:alt when the Twitter versions are missing. The tags with no Open Graph match include twitter:site, and twitter:card sets the card type, so my advice is to set those two yourself.
The same reference says that if og:type, og:title and og:description exist but twitter:card is absent, then "a summary card may be rendered" by X. For the large layout, X's Summary Card with Large Image page, also an archive copy, requires summary_large_image and says images support 2:1 from 300x157 to 4096x4096 pixels, under 5MB. The sources conflict on one point: the Cards markup reference says either twitter:site or twitter:site:id is required, but the large image page marks twitter:site as not required. My advice is to set it, since it costs one line.
Does Google Search use any Open Graph data?
Yes, but only in two narrow places that these docs name. Google Search Central lists og:title among the sources Google uses for title links, and its site name page says Google will also consider og:site_name. Neither page calls Open Graph a ranking factor, and the site name page says WebSite structured data matters most if you want to state a preference.
The title link page lists content in og:title meta tags as one of nine sources Google uses "to automatically determine title links" alongside the title element and headings. Our post on why Google rewrites title tags covers that system in depth. For site names, our guide to Google site names and favicons covers the WebSite structured data that matters most, and since Open Graph is not schema.org, our JSON-LD schema markup guide covers that separate vocabulary.
How do you set og:locale for other languages and countries?
Set og:locale to the language and territory of the page, in the language_TERRITORY format the spec describes. The spec and Meta both say the default is en_US, so any page in another language should state its own locale. Use og:locale:alternate, which the spec defines as an array, to list the other locales this page is available in.
For example, a German page would use de_DE and a Korean page would use ko_KR, which follows the spec's language_TERRITORY pattern. A Seoul skincare brand with Korean and English pages would set ko_KR on the Korean page and en_US on the English one. In my opinion og:locale does not replace hreflang, which tells search engines about language versions, so follow our hreflang and international SEO guide for that part.
How do you mark up articles, video and more than one image?
For a blog post, set og:type to article and add the article properties the spec lists, such as article:published_time, article:modified_time, article:author, article:section and article:tag. For several images, repeat the og:image tag, and the spec says the first one wins in a conflict. Video uses og:video, which the spec says has the same structured tags as og:image.
Meta says video needs a secure URL in og:video:url and og:video:secure_url to be eligible to play inside Feed, though play is not guaranteed. For the search side, see our guide to video SEO on Google Search and YouTube. If you post to Pinterest, our Pinterest SEO guide explains how Rich Pins read Open Graph data from your page.
How do you audit your Open Graph tags, and what should you fix first?
Open one page per template, view its source, and find each meta tag whose property starts with og. Confirm the four required properties, load the image URL in a browser, run the page through the Sharing Debugger, and check that the server returns a 200 status to a crawler. Fix missing images first, then stale or generic ones.
Add this audit to our SEO checklist for individual pages, which has one step on social previews. If a crawler gets an error instead of a 200, nothing else matters, and our guide to how HTTP status codes shape crawling explains each code. Check your CMS first, because our Webflow SEO setup guide notes that Webflow has no global Open Graph image, so pages show none until you set one.
Fix the template that sets the four required properties first, then add og:image:alt, image sizes and twitter:card. After that, take the page you share most, compare its Open Graph tags with the table above, and run it through the Sharing Debugger.
Frequently asked questions about Open Graph
Do Open Graph tags help my Google rankings?
None of the sources behind this guide say so, and I would not add Open Graph tags expecting a ranking lift. The two Google pages behind this guide name og:title as a source for title links and og:site_name as one input for site names. That matches the view in our guide to fixing WordPress SEO defaults, which calls an SEO plugin's social preview tab a convenience, not a ranking feature. Set them for the people who share and click your links, since that is where the payoff shows up.
Is og:type really required on an ordinary page?
The spec lists og:type as one of the four required properties, so the strict answer is yes. The same spec also says a page with no markup should be treated as the website type, and Meta's Webmasters guide says the default is website when you leave it out. So in my reading a missing og:type on a plain page is a small gap, not a broken card. I would still set it on every template, using website for home and landing pages and article for posts.
Can I use one og:image for every page on my site?
You can, but X's large card page says you should not use a generic image such as your website logo, author photo, or an image that spans many pages. The spec also describes og:image as an image that should represent your object, which a sitewide logo does not. My advice is to give each key page its own image and keep a branded default only as a safety net for pages you have not reached yet. A default beats an empty card, but it should never be the plan.
Should og:url include tracking parameters?
No, Meta's Webmasters guide says og:url should be the undecorated URL, without session variables, user identifying parameters, or counters. It adds that mobile domain URLs should point to the desktop version so likes and shares gather across versions of the page. My advice is to strip campaign tags from og:url and let them live only in the links you share, so every share counts toward one clean address. If your canonical URL is already clean, copying it into og:url is the simplest fix.
What happens if my theme and my SEO plugin both output og:image?
The spec allows repeated tags and says "The first tag (from top to bottom) is given preference during conflicts" so the image higher in your source should win. That still leaves two sets of Open Graph tags fighting over one page, and a later edit to one of them can change the card without warning. My advice is to view the source, find which tool writes each set, and switch one off. Then run the page through the Sharing Debugger to confirm only one image remains.
How can I tell if my server blocks the Facebook crawler?
Meta's Webmasters guide describes a simple test that needs only a browser with a developer menu. Set the browser's user agent to facebookexternalhit, load the problem URL, then switch the user agent to a mobile Safari browser and load it again. Meta says that if the page loads with the mobile browser but not with the crawler user agent, the user agent is the issue. In that case, ask whoever runs your firewall or bot rules to let the crawler through, then run the Sharing Debugger again.
Can I use an SVG or an animated GIF as my preview image?
Skip SVG, because X's Cards markup reference says plainly that SVG is not supported. Animated GIFs are allowed there, but X says only the first frame will be used, so the motion is lost. Meta's Webmasters guide lists image/jpeg, image/gif and image/png as the types for og:image:type, which points the same way. My advice is to export a JPG or PNG for every preview, keep it under the 5 MB limit LinkedIn and X both state, and save the clever formats for the page itself.
Do I need the fb:app_id tag?
In my reading, only if you plan to use Facebook Insights. Meta's Webmasters guide lists fb:app_id among the basic tags for all content types and says that to use Facebook Insights you must add the app ID to your page. Meta describes Insights as a way to view analytics for traffic to your site from Facebook, and you find the app ID in your App Dashboard. If you have no plans for Insights, I would leave the tag out and spend that time on the four required properties instead.
Do I need og:determiner or og:audio?
Both sit on the spec's list of optional properties that are generally recommended, but in my view most pages can live without them. The spec defines og:determiner as the word that appears before your title in a sentence, chosen from a, an, the, a blank, or auto. The og:audio property points to an audio file that goes with the object, which suits a podcast episode page more than a blog post. I would set og:description and og:site_name first, since Meta shows the description below the title and Google considers og:site_name for site names.
Do I still need og:image:alt if I set twitter:image:alt?
Set og:image:alt well and, in my reading of the docs, you may not need the X version at all. X's Cards markup reference says twitter:image:alt falls back to og:image:alt, and it caps that text at 420 characters. The spec says a page that sets og:image should set og:image:alt, and describes it as what is in the image, not a caption. So write one plain line about what the picture shows, keep it well under the 420 character cap, and let X reuse it.