📱 Open Graph Preview

When someone shares your URL on social media, they are not sharing a bare link — they are handing the platform a set of instructions for building a visual card. That card is constructed almost entirely from your Open Graph meta tags. Get them right and you get a polished, high-contrast preview that drives clicks. Get them wrong and you might see your site's favicon on a grey background, a title chopped mid-word, and a description that reads like an autogenerated breadcrumb string. The gap between those two outcomes is surprisingly small to fix, and almost entirely within your control.

How Facebook, LinkedIn, and Twitter Each Read Your Tags

All three platforms start from the same Open Graph standard, but they diverge in ways that matter. Facebook is the most forgiving and also the most aggressive with caching. It scrapes your page with the Open Graph Object Debugger (now called the Sharing Debugger) and holds that snapshot for weeks. You can force a refresh by submitting the URL to the Sharing Debugger, but a surprising number of developers discover this only after a botched launch.

LinkedIn plays it even stricter. It pulls og:title, og:description, og:image, and og:url, but the description is almost never shown in the standard feed post card — only the title and domain appear below the image. This shifts the entire weight of your first impression to two things: the image and the title. LinkedIn also caches aggressively; their Post Inspector tool exists specifically to let you bust that cache and re-scrape your URL.

Twitter (now X) uses its own parallel system called Twitter Cards, which maps to OG tags as a fallback. If you have twitter:card, twitter:title, and twitter:image set, Twitter ignores your OG tags for card rendering. If you do not, it falls back to og:title and og:image. The two card types you will actually use are summary (thumbnail on the left, text on the right) and summary_large_image (full-width hero image above the text). The latter is what almost everyone wants, but if your image is too small — under 144×144 px for summary, or under 300×157 px for large — Twitter silently falls back to the smaller layout or drops the image entirely.

Image Dimensions: The Most Common Silent Failure

The canonical recommendation is 1200×630 pixels, which maps to a 1.91:1 aspect ratio. Facebook, LinkedIn, and Twitter all render this cleanly. What breaks things is when developers use a square image (1:1) or a tall portrait image: Facebook crops it differently than Twitter, so you end up with a card that looks fine on one platform and shows someone's chin cut off on another.

There is a second trap: file size. Facebook has documented a 8MB limit, but in practice anything over 2–3MB causes noticeable delays in card loading. Twitter requires images to be under 5MB for photos. If your marketing team hands you a 7MB Photoshop export, that image will work in your browser but potentially fail in the Twitter Card validator with a cryptic error about the image being inaccessible — which actually just means the response was too slow.

The third and subtlest issue is HTTPS vs. HTTP. All three platforms require the OG image to be served over HTTPS. An HTTP image URL will result in no image on Twitter and a broken image icon on LinkedIn, even if the URL itself works fine in a browser.

Title and Description Length: What Actually Gets Truncated

There is a lot of conflicting advice about the "correct" length for OG titles and descriptions, partly because each platform renders text differently depending on screen width, font rendering, and the version of their mobile app. Here is what actually happens in practice:

Facebook cuts og:title at roughly 60–88 characters. The variance comes from proportional fonts — a title full of lowercase "i" characters will display more text than one full of "W"s. Facebook's description cutoff is similarly fuzzy, somewhere between 155 and 200 characters in a desktop feed, often much shorter on mobile. LinkedIn's feed card shows only the title and domain — no description in the standard link post — so description length matters much less there. Twitter large cards show around 70 characters of title and 2 lines of description (roughly 125 characters) before cutting off with an ellipsis.

The practical rule: write your title under 60 characters, your description between 100 and 155 characters, and assume the first sentence of the description is the only one that counts.

Previewing Before You Publish: Why It Matters More Than Most Teams Realize

The classic developer workflow is to push the page live, share the URL in Slack, and then discover the OG image is pulling from the old homepage image because a WordPress plugin cached the wrong value. By then, anyone who already saw the bad card in their feed saw the bad card — social media feeds do not auto-refresh old embeds.

Facebook's Sharing Debugger and Twitter's Card Validator both require a live, publicly accessible URL. This creates a frustrating chicken-and-egg problem: you cannot validate until you deploy, but you do not want to deploy until you validate. Tools that let you preview directly from tag values — without needing a live URL — solve this by letting you confirm the visual output locally or in a staging environment before DNS ever changes.

LinkedIn's Post Inspector is also live-URL-only, and it has an additional quirk: it will sometimes return cached data from a previous scrape even when you explicitly ask it to re-scrape. Hitting the "Inspect" button multiple times and checking the "Last scraped" timestamp is the only reliable way to confirm you are seeing fresh data.

The Tags Most Developers Forget

og:type is the first one — default behavior without it is "website," which is fine, but setting it explicitly to "article" for blog posts unlocks additional structured data behavior on some platforms. og:site_name is the second — this appears in Facebook's grey domain bar under the image. If you leave it out, Facebook falls back to the raw domain, which means "mybrand-global-llc.com" instead of "MyBrand." LinkedIn ignores it entirely and always uses the domain. Twitter does not use it at all.

og:locale matters if you run a multilingual site. Without it, Facebook assumes en_US. If you are serving Japanese content on a Japanese domain, setting og:locale to ja_JP and including the correct og:locale:alternate for English helps Facebook route content recommendations correctly, even if it has zero visible effect on the card itself.

Common Mistakes That Look Fine in Dev but Break in Production

Relative image URLs (/og-image.jpg instead of https://yoursite.com/og-image.jpg) work in a browser that knows the current domain but fail completely when Facebook's scraper encounters them as standalone meta content. This mistake accounts for a surprising percentage of "broken card" bug reports.

Dynamic OG tags — generated server-side for user profiles, product pages, or article pages — often break when a CDN caches the first scraped version and serves that same HTML to all subsequent scrapers, even after the underlying content changes. The fix is to ensure your CDN passes crawler User-Agent strings through to origin, or to set Cache-Control: no-store for the meta tag portion specifically if your platform supports fragment-level caching.

Finally, template-level og:image placeholders left as empty string values (content="") cause more problems than a missing tag altogether. Some platforms interpret an empty content attribute differently from a missing tag. Facebook will sometimes show a "loading" spinner indefinitely rather than falling back gracefully. Always conditionally render OG image tags rather than outputting an empty one.

The difference between a well-optimized OG setup and a neglected one is not just aesthetics — it is whether the people who share your content are accidentally working against you every time they paste a link.