What Open Graph tags do for your link previews
When a user pastes your URL into Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage, Microsoft Teams, or just about any modern messaging surface, the receiving platform fetches your page and looks for Open Graph (og:*) meta tags in the head. Those tags determine the preview card the platform renders: the image, the title, the description, the site attribution. Without them, you get plain text, a broken-looking thumbnail, or whatever scrape the platform can stitch together from raw page content. With them, your link looks intentional.
Open Graph started as a Facebook-only protocol in 2010 and has since become the de facto standard for nearly every social and messaging platform on the web. LinkedIn uses og:*. Slack uses og:*. Most chat apps fall back to og:* even when they have their own preferred tag set. So shipping clean Open Graph markup buys you good-looking previews almost everywhere with one block of HTML.
The required four tags
og:title is the bold headline that appears under the image. It can match your html title tag or differ; many sites use a cleaner, brand-free version for social. Aim for 60 characters or fewer to avoid truncation across platforms; LinkedIn cuts earlier than Facebook.
og:description is the smaller text under og:title. Aim for 100 to 160 characters. Below 100 looks thin; above 200 gets cut on most platforms. Like a meta description, write for the click, not for keywords; the platforms do not weigh keywords here.
og:image is the single highest-impact field. It is what the eye sees first in any feed. Without it, most platforms fall back to a header logo, a random scraped image, or no image at all (LinkedIn renders a tiny gray placeholder). Always set og:image with an absolute https URL.
og:url is the canonical URL of the page being shared. This prevents tracking parameters and session URLs from creating duplicate cached previews per query string. Set it to the same URL as your canonical link tag.
Image specs and the 1200 by 630 rule
Use 1200 pixels wide by 630 pixels tall (a 1.91:1 aspect ratio). This is the Facebook recommendation and works on every other platform that consumes Open Graph. Smaller images get upscaled and look fuzzy. Larger images get cropped or downscaled.
Keep file size under 8 megabytes (the Facebook hard limit) but aim for under 300 kilobytes for performance. Use JPG or PNG; GIF and WebP support is inconsistent across platforms. Avoid text-heavy images: many platforms reduce the image size in feeds and small text becomes unreadable. Bold focal imagery, a clear logo position, and at most a five-word headline work best.
Add og:image:width and og:image:height meta tags. They give platforms layout hints before the image finishes downloading, which prevents the card from reflowing and keeps the design consistent. Add og:image:alt with a short description for accessibility on platforms that read it aloud.
og:type and why it matters
og:type tells the platform what kind of content this is. Default to "website" for landing pages and most content. Use "article" for blog posts and editorial content; some platforms render slightly richer cards for articles, and Facebook Instant Articles requires it. Use "product" for ecommerce pages with price and availability, "profile" for person pages, and the music or video sub-types for media-specific pages.
Each type unlocks additional optional tags. article supports article:published_time, article:author, and article:tag. product supports product:price:amount and product:price:currency. These are not always rendered in previews but they enrich downstream platforms that consume the feed (RSS readers, news aggregators, AI search tools).
Open Graph vs Twitter Card vs Schema
These three are layered, not redundant. Open Graph covers Facebook, LinkedIn, Slack, and the long tail of modern messaging apps. Twitter Card covers X (Twitter) and a few adjacent platforms. Schema.org JSON-LD covers Google search and AI search systems (ChatGPT search, Perplexity, AI Overviews). For full coverage, ship all three; they do not conflict.
That said, Twitter falls back to Open Graph when Twitter Card tags are missing. So if your time budget is limited, ship complete og:* tags first; the og:image and og:title will carry through to most surfaces. Then add Twitter-specific tags (twitter:card, twitter:site) for the X-specific UX, and add Schema for search.
Common mistakes and how to test
Relative image URLs. Open Graph requires absolute URLs starting with https. A relative path like "/og.jpg" silently fails on every consumer. Always use the full domain.
Cached old previews. Once Facebook has scraped your URL, it caches the preview for 24 hours. If you change your og:image and resharing still shows the old one, run the URL through the Facebook Sharing Debugger and click "Scrape Again" to refresh the cache. LinkedIn has a similar Post Inspector tool.
Duplicate or conflicting tags. CMS plugins, theme defaults, and analytics scripts sometimes inject their own og:* tags alongside yours, leaving multiple og:title or og:image entries in the head. Most platforms pick the first occurrence, but the behavior is undefined. Use the browser inspector to confirm only one of each og:* tag is rendered, and remove duplicates at the source.
Always test before announcing. Paste your URL into a private Slack channel, a Facebook draft, and a LinkedIn message compose box (without sending) to see the real preview. The live render almost always reveals at least one issue the in-page preview missed.
How this preview and generator works
The tool does two jobs. First, it renders a live preview card the way Facebook, LinkedIn, and Slack would draw it, so you can see the image crop, the title wrap, and the description trim before any platform caches them. As you edit og:title, og:description, and og:image, the card updates instantly, which turns guesswork into a design surface. Second, it generates the clean block of og:* meta tags for you to paste into your page head, so you do not have to remember the exact property names or the order they belong in.
The generator output uses absolute https image URLs, includes the width and height hints, and follows the 1200 by 630 default unless you change it. That means the markup you copy is already compliant with the rules that trip most people up. You still verify against a real platform afterward, because caching and moderation live outside your markup, but starting from correct tags removes the most common class of failure entirely.
Why the og:image fails more than any other tag
If a link preview looks broken, the image is almost always the reason. The failure modes are predictable. A relative path instead of an absolute https URL means no platform can resolve it. An image hosted behind authentication or a hotlink-protection rule returns a forbidden response to the platform's scraper even though it loads fine in your own browser. An image smaller than the recommended dimensions gets upscaled into a blurry mess. An image with the wrong aspect ratio gets cropped, often slicing off the headline text you carefully centered.
The preview here catches all of these by showing you the actual rendered crop rather than the raw file. If the card looks wrong in the preview, it will look wrong in the feed. The fix is usually to swap in a properly sized 1200 by 630 image served from a public https URL, keep any important text away from the edges, and confirm the file is light enough to load fast. An image that takes too long to fetch sometimes gets skipped by a platform's scraper, leaving you with a text-only card despite valid markup.
Open Graph for AI search and link unfurling in 2026
Open Graph started as a social-sharing convenience, but in 2026 the same tags get consumed in more places than ever. AI search tools and chat assistants that surface links increasingly render an unfurled card, and they pull og:title, og:description, and og:image to build it, just like a messaging app does. A clean Open Graph block therefore shapes how your link looks not only in a feed but also when an AI engine cites you with a visual preview. Pages with no og:image become a flat text link in those surfaces, which earns far less attention.
The takeaway is to treat Open Graph as part of your core metadata rather than a nice-to-have for the marketing team. Every page you actually want shared or cited should carry a complete, accurate og:* set, and the image should communicate the page topic at a glance, because in a feed or an AI answer the image is read before the words. Using the preview to sanity-check that image at its real rendered size is the cheapest way to make sure your links look intentional wherever they end up.
Shipping Open Graph across templates, not just pages
The fastest way to get Open Graph wrong at scale is to set it once on the homepage and forget the templates. Blog posts, product pages, and category pages each need their own og:title, og:description, and ideally their own og:image, because a single site-wide image makes every shared link look identical and generic. Many sites solve this by generating a dynamic og:image per page that includes the page title baked into a branded template, so every share is distinct without manual design work.
Whatever approach you take, test the template with a real example from each page type rather than assuming the homepage result carries over. Use this preview on one representative blog post, one product, and one category page, confirm the per-page values resolve correctly, then trust the template for the rest. After any theme update, plugin change, or migration, re-test, because those are the moments a working og:* setup quietly reverts to a default or starts emitting duplicate tags that confuse the consuming platforms.