Last updated: 2026-09-05

OGP Text Optimization - Improve Social Media Share Displays

Open Graph Protocol (OGP) controls how your web pages appear when shared on social media. Created at Facebook and published in 2010, it is an RDFa-based metadata vocabulary, and as of August 2026 it is widely adopted across the major social networks and messaging apps. Without proper configuration, titles get cut off partway through and unintended descriptions appear, and the link loses its appeal. This guide covers OGP text optimization and how to tell what the official specification actually settles from what it leaves open.

OGP Specification and History

OGP originated at Facebook as a metadata standard and was published in 2010 to standardize how web pages are represented in social feeds. The specification, published at ogp.me, defines four properties as required for every page: og:title, og:type, og:image, and og:url. These are placed as <meta property="og:..."> tags within the HTML <head> element. The first version of the specification was built on RDFa, which is why the tags use the property attribute rather than name.

The point worth holding on to is that ogp.me defines only which properties to write and how to write them. It sets no character limit whatsoever for og:title or og:description. For og:description it says only that the value is a one- to two-sentence description, with no length given. Every character-count guideline that follows in this guide is therefore a practical figure derived from how platforms display cards, not a number the specification or the platforms guarantee.

Before OGP, social platforms scraped the <title> tag and <meta name="description"> to generate link previews. However, these elements were optimized for search engines and often produced awkward or overly long previews in social feeds. OGP solved this by providing a dedicated metadata layer specifically for social sharing.

Why No Official Display Length Exists

How much OGP text a platform shows is usually discussed through per-platform tables of character limits. As of August 2026, however, none of the major social platforms publish an official figure for how many characters of og:title or og:description they display. The reason lies in the rendering itself: how much text fits depends on the screen width of the device, the font, the user's text-size setting, and the card type (a small thumbnail layout or a large image layout). There is no fixed number of characters to state in the first place.

Two practical rules follow. The first is to build truncation into your design as the default behavior rather than an exception. The second is to stop guessing where the cut will fall and instead use a word order that still works wherever it falls. In English that means putting the substance up front: "5 Ways to Cut Your Build Time" keeps its meaning even if the tail is dropped, whereas "A Guide to the Five Techniques We Use for Cutting Build Time" loses the subject the moment the ending disappears.

As a working guideline, keeping og:title to around 40 characters and og:description to roughly 70–100 characters leaves the essential part readable in most environments. These are not limits guaranteed by anyone; treat them as practical margins chosen on the assumption that truncation will happen.

Optimizing og:title

og:title is the most prominent element of a shared card. Because it can be set separately from the page's title tag, you can write one version aimed at search results and another aimed at a social timeline.

The points below help when writing an effective og:title.

• Keep it to around 40 characters: leave enough margin that the subject survives being cut
• Omit the site name: link cards normally show the domain alongside the title, so spend the limited space on the article itself
• Put the key information first: leading with a number or the intended reader keeps the topic clear even when the ending is lost
• Questions and direct address are options: but a question the article never answers reads as a letdown and works against you

og:title vs. HTML Title Mismatch Behavior

og:title and the HTML <title> tag are independent elements that can have different values. Platform crawlers prioritize og:title, but fall back to the <title> tag when og:title is not set.

Be careful, though, when the two say very different things. Google's own documentation states that when it generates the title link for a search result, it may draw on og:title alongside the <title> element and the page's headings. In other words, og:title is not a social-only setting; it can affect how the page looks in search results too.

One related point is easy to get wrong. Google rewrites a title link when it detects a problem on the page, and the representative cases it lists are titles that are half empty (nothing but "| Site Name"), titles that do not match the content, titles left stale with an old year in them, boilerplate repeated across many pages, pages where no main heading can be identified, and titles written in a different language from the body. Length is not among the listed reasons. A long title tag is not rewritten; it is simply truncated to fit the available width. These are two separate phenomena, so avoid concluding that a title "was rewritten because it was too long."

As a way to divide the work, write the title tag as the descriptive form that includes the words matching search intent, and og:title as the concise form that catches the eye in a timeline, keeping the subject of both the same. Once the subjects diverge, the content and the first impression conflict for readers arriving from either route.

Writing og:description

og:description is the supporting text shown below the title. Its job is to fill in what the title alone cannot carry and to give the click a final push.

Aim for roughly 70–100 characters. Put the most important information in the opening 40 or so, so the sentence still makes sense if it is cut partway through. Using the same content as your meta description is fine, but search results and timelines are read differently, so writing a more conversational variant for social is also effective.

og:description Fallback Behavior

When og:description is not set, each platform generates fallback text with its own logic. Facebook uses the value of <meta name="description">, and if that is also missing, it auto-extracts the opening text of the page body. X gives priority to the twitter: tags and refers to the og: tags when those are not set. If neither exists, the text is picked up from the page itself.

Auto-extracted text often includes navigation menus and sidebar content, resulting in unintended previews. Always set og:description explicitly. Use Character Counter to verify your og:title and og:description lengths stay within each platform's display limits.

Designing the OGP Image (og:image)

The OGP image decides what the link card looks like. It occupies far more area than a text-only link, which is what makes the card noticeable in a feed.

Keep the text placed on the image to a handful of words, five to ten at most. Cards are displayed at reduced size inside a timeline, so packing characters into the image makes them unreadable on small screens. Rather than pouring the whole article title into the graphic, pull out only the core phrase.

For size requirements, Facebook does publish concrete numbers in its official documentation: a minimum of 200×200 pixels, at least 1200×630 pixels once high-resolution displays are taken into account, at least 600×315 pixels for a link post to be shown with a large image, an aspect ratio as close to 1.91:1 as possible, and a file size no larger than 8 MB. The table below includes rows for other platforms, but for those rows some values are not stated officially anywhere; they are collected here as practical figures in wide use as of August 2026.

• Image size: use 1200×630px (landscape) as the baseline. The official ceiling is 8 MB, but in practice keeping the file under 1MB protects loading speed
• Text placement: keep it in the center to upper area, since the bottom may overlap with the platform's own UI
• Font size: secure at least 40px
• Background: keep enough contrast against the text, using WCAG AA (a contrast ratio of 4.5:1 or higher) as the target

Platform Crawler Behavior

The crawlers that fetch OGP information behave differently from platform to platform. Facebook's crawler (facebookexternalhit) can be identified by its User-Agent header, and it does not execute JavaScript. That is why sites generating OGP tags dynamically through client-side rendering (CSR) run into the problem of their OGP information never being read correctly.

X's Twitterbot, LINE's crawler, and Slack's Slackbot likewise parse the HTML exactly as it comes back. Seeing the OGP tags in your browser is therefore not a verification. The criterion is whether the raw HTML retrieved with something like curl contains the og: tags.

If you're using SPA frameworks like React or Vue.js, OGP tags must be output via server-side rendering (SSR) or static site generation (SSG). Next.js's generateMetadata and Nuxt's useHead provide framework-native ways to output OGP tags correctly.

OGP Cache Mechanism and Update Methods

Every platform caches OGP information, so updating the tags on a page is not reflected right away. As of August 2026 none of the platforms publish an official figure for how long the cache is held, so you should avoid any workflow that assumes "it expires in N hours." In practice, rather than waiting for an expiry, decide your approach based on whether an explicit way to refresh the cache exists.

• Facebook: entering the URL in the Sharing Debugger and running "Scrape Again" re-fetches it on the spot. Treat this as the one route that comes with a way to confirm the update
• Other platforms: in many cases no official means of discarding the cache by hand is provided, which leaves you waiting until the update is picked up
• Slack: re-pasting a URL may still show the old content. The workaround is to append a query parameter (for example ?v=2) so that Slack treats it as a different URL

The practical lesson this asymmetry leads to is to finish your checks before publishing. If you fix og:title after the fact, you have no control over when the fix appears. For pages where the first hours matter, such as a campaign or an announcement, the safe move is to share the URL yourself and look at the preview before handing it to anyone else.

Using OGP Debugging Tools

Once OGP is configured, checking the display with each platform's debugging tool is indispensable. Publish without noticing a configuration mistake and the unintended display is spread further every time the page is shared.

The main debugging tools and how to work through them are as follows.

• Facebook Sharing Debugger: entering a URL shows a preview of og:title, og:description, and og:image. Missing properties and undersized images are reported as warnings, so passing through here first is the basic step
• LinkedIn Post Inspector: lets you check both the share display on LinkedIn and the contents of the metadata that was retrieved
• Preview via a draft post: on platforms where no validation tool is provided, or where its availability has changed, the reliable method is to paste the URL into the composer, look at the card, and discard the draft without posting

It is safer to keep one check that does not depend on an external tool. Fetching your own page with curl and looking at whether the returned HTML contains the og: tags shows you exactly what a crawler receives, so it holds regardless of any single platform's circumstances.

Folding the pre-publication check into one routine reduces omissions. The basic two-step is to verify the length of og:title and og:description with Character Counter, then look at how the card renders in a debugging tool or a draft post.

CMS-Specific OGP Configuration

Major CMS platforms and frameworks each have their own approach to OGP configuration:

• WordPress: Plugins like Yoast SEO or All in One SEO Pack provide a GUI for OGP settings. The "Social" tab in the post editor lets you set og:title and og:description independently
• Next.js: Use the generateMetadata function to return an openGraph property, dynamically generating OGP tags per page
• Nuxt: Configure OGP meta tags via the useHead composable or nuxt.config.ts's app.head
• Static HTML: Write <meta property="og:..."> tags directly in the <head>. Use template engines to inject dynamic values when applicable

Dynamic OGP Generation Pitfalls

When generating OGP tags dynamically based on user input or database values, several pitfalls require attention.

First, HTML escaping is essential. If og:title or og:description includes user input, failing to escape <, >, &, and " creates HTML injection vulnerabilities.

Second, when og:image is generated dynamically (for example through Vercel OG Image Generation or Cloudinary transformations), a slow generation step risks the crawler abandoning the fetch. The platforms do not publish how long they wait, so rather than trying to leave yourself a margin, build the page so that even the first request returns immediately. Cache the generated result in advance, or serve it through a CDN.

Third, when URLs contain query parameters or fragments, set og:url to the canonical URL (without query parameters). This prevents share counts from being split across different URL variations of the same content.

What Changes Is the Display, Not the Specification

Run OGP for long enough and you will come across the claim that "the specification changed, so everything has to be rebuilt." What has actually changed, though, is not the ogp.me specification but the way each platform displays cards. The set of required properties, og:title, og:type, og:image, and og:url, has not changed since publication, and there has never been a point where the way you write them had to be rewritten. The card layouts and the recommended image sizes, on the other hand, have been updated as device resolutions improved and the apps were reworked.

That asymmetry maps directly onto maintenance priorities. You almost never need to revisit how the tags are written; what deserves periodic checking is whether the image still displays at the ratio you intended. On older sites in particular, an image made for the recommended size of its day can look coarse inside today's larger cards. Correct tags with a poor-looking card is a state reached through exactly this route.

OGP and Twitter Card

X (formerly Twitter) maintains its own Twitter Card meta tags (twitter:card, twitter:title, etc.), but falls back to OGP tags when Twitter Card tags are not set. This means properly configured OGP tags provide basic display coverage even without Twitter Card tags. However, the twitter:card tag has no OGP equivalent and must be set explicitly.

Common Mistakes

• Making og:title exactly identical to the title tag, which leaves the chance to write separately for social unused. The title tag can be the descriptive form containing the words that match search intent, while og:title is shaped to convey the content at a glance in a timeline
• Getting shared with no og:image set, so the platform displays an image it picked by itself. When a logo or an icon unrelated to the article is chosen, the link never communicates what information it holds
• Not setting og:url, or writing it as a relative path. og:url must always be an absolute URL starting with https://. A relative path fails to resolve on some platforms and becomes a cause of share counts splitting across pages
• Omitting og:type. ogp.me defines og:type as a required property, and leaving it out hands the decision over to whatever the platform treats as its default. Specifying article for a blog post also makes the type-specific properties, such as publication date and author information, available

Pro OGP Techniques

• Put the most important words at the start of og:title: timelines are skimmed, and the tail is liable to be cut, so front-loading the information works for both conditions at once
• Hold down the area the text occupies on the OGP image: filling the image edge to edge with characters makes it unreadable once reduced, and the image itself stops doing its job of signalling what kind of card this is
• Do not let og:description repeat the title: adding one concrete detail from inside the subject the title named increases how much the card conveys as a whole
• Compare the traffic before and after changing og:title: the same article draws different reactions when the wording changes, so on pages where sharing is a main route in, recording the result of each change accumulates something to judge by.

Conclusion

There are two points to hold on to when optimizing OGP text. The first is the premise that the ogp.me specification defines no character limit, and that the platforms do not officially publish how many characters they display either. You therefore cannot design around the idea of "how many characters will avoid being cut." The realistic answer is to stay within the practical guidelines of around 40 characters for og:title and roughly 70–100 for og:description, while using a word order that leaves the subject intact wherever the cut falls. The second is that OGP tags are independent of the HTML title tag and meta description, which lets you write one version for search results and another for timelines. Because you cannot control when a post-publication fix is reflected, share the URL yourself and check the preview before handing it out. Verifying the length of og:title and og:description with Character Counter beforehand keeps you from publishing while far over what you assumed.