SEO
Free Open Graph and Twitter card tag generator
By Charles Summers · Updated · Free, no signup
Short answer
This emits the full og: and twitter: meta tag set for your page, then measures your title and description against the point at which each platform actually cuts them, showing the truncated string rather than just a character count. Facebook clips headlines around 60 characters, X renders the headline as an overlay on the image and drops the description entirely, and LinkedIn shows title and domain with no description at all, so one length target for all of them is guaranteed to be wrong somewhere.
Use the open graph tag generator
What does this tool actually do?
This emits the full og: and twitter: meta tag set for your page, then measures your title and description against the point at which each platform actually cuts them, showing the truncated string rather than just a character count. Facebook clips headlines around 60 characters, X renders the headline as an overlay on the image and drops the description entirely, and LinkedIn shows title and domain with no description at all, so one length target for all of them is guaranteed to be wrong somewhere..
It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.
Every platform truncates somewhere different, and two ignore the description
There is no single Open Graph character limit, because og:title and og:description are not rendered by a shared component. Each platform draws its own preview card at its own fixed dimensions and clips whatever overflows, so the same tags produce four different results in four apps. The counts below are bands rather than exact numbers, because the cut depends on screen width, the reader’s font size and which letters you used, exactly as it does with a search snippet.
Facebook clips the link headline at roughly two lines in feed, which lands somewhere near sixty characters on a phone and a little further on a wide desktop window. Its description sits underneath at a smaller size and is cut around one hundred and ten characters on mobile, further on desktop. X is the odd one out: since it changed link cards, a summary_large_image renders the headline as a small overlay strip along the bottom of the image and does not display the description at all in the timeline, so any effort you put into a persuasive og:description is invisible to that audience.
LinkedIn shows the image, the title across up to two lines, and the domain, with no description text in the feed. Slack, Discord and iMessage unfurls are the generous end of the range: they show title and description close to in full, which is why a link that looks fine in a team chat can be clipped mid-word on Facebook. Write the first sixty characters of the title so it stands alone, and put the qualifying detail in the first hundred characters of the description, and you have covered the strictest case without shortchanging the generous ones.
The absolute URL rule, and why relative image paths fail every time
og:image must be a fully qualified URL, protocol included. This trips people up more than any other part of the spec because relative paths work everywhere else in HTML: an img tag with src="/img/hero.jpg" resolves against the document, so it looks correct in a browser and the developer assumes the meta tag will behave the same way. Crawlers reading Open Graph tags treat the content attribute as a literal URL, and a literal /img/hero.jpg is not a URL that resolves to anything. The preview falls back to no image, or to whatever unrelated picture the crawler scraped from elsewhere on the page.
Protocol-relative URLs beginning with two slashes are the subtler version of the same problem, and they still appear in older CMS themes. The other frequent causes are all environmental rather than syntactic: a staging hostname baked into the template and shipped to production, an http:// image on an https:// page, an image directory disallowed in robots.txt, a CDN with hotlink protection that returns a 403 to any request that is not a browser, and images behind a login. Every one of those produces a syntactically perfect tag and an empty preview.
Then there is caching, which turns a five-minute fix into an afternoon. Facebook stores what it scraped and keeps serving it, so correcting the tag changes nothing about links already shared until the URL is re-scraped through the Sharing Debugger. LinkedIn has its own post inspector for the same reason. Test the fix with the platform’s own tool rather than by pasting the link into a draft post and squinting, because a draft post shows you the cache, not your code.
The image spec: 1200x630, 1.91:1, and what happens at the edges
The recommended og:image is 1200 by 630 pixels, which is the 1.91:1 ratio the large link card is drawn at. The ratio matters more than the absolute size: get it right and the image fills the card exactly, get it wrong and the platform crops to fit, always from the centre, which is how logos lose their top half. Facebook documents 600 by 315 as the practical minimum for a large card, and images smaller than that degrade to a small square thumbnail beside the text instead of the full-width image. Below roughly 200 pixels on a side it will not render at all.
X crops a summary_large_image closer to 2:1, so a 1200 by 630 image loses a sliver from the top and bottom on that platform. The working rule is to keep anything that must be legible inside a central safe area with about forty pixels of margin top and bottom, and to design for the card being displayed at maybe a third of its native size on a phone. Twelve words of small text in a hero image is a design that only works in the mockup.
Format and weight matter too. SVG is not rendered by these crawlers, so an SVG og:image is a blank card. Animated GIFs render as their first frame. Very large files are the usual explanation for a preview that appears everywhere except one app, since the messaging clients are stricter about download size than the social feeds are. Two tags remove most of the remaining uncertainty: og:image:width and og:image:height let a platform lay the card out before it has finished downloading the image, which is why a first share sometimes appears with a blank space where the picture should be, and og:image:alt supplies the alt text that screen readers read from the card.
Fallback order, duplicate tags, and the ones people forget
The namespaces fall back in a defined order, and knowing it stops you writing twice as many tags as you need. If og:title is missing, platforms use the HTML title element. If og:description is missing, they use the meta description. The twitter: namespace falls back to og: for title, description and image, so the only tag that is genuinely mandatory on that side is twitter:card, which has no og: equivalent. Emitting the twitter: duplicates anyway is defensible when you want a different headline for that audience, and pure noise when the values are identical.
og:url is the tag most often set wrong, and it has a real consequence. It should be the canonical URL of the page, not the URL with the tracking parameters that happened to be in the address bar. Platforms key their share counts and engagement to this value, so a page reachable at five parameterised variants with five different og:url values splits its own engagement five ways. Set it to the same string as your rel=canonical and the problem disappears.
A few smaller ones are worth the two minutes. Multiple og:image tags are allowed and the first is used as the primary, so ordering matters if you list several. og:locale defaults to en_US, which is worth overriding if you are not writing American English, and og:locale:alternate is how you point at your translations. og:type changes which extra namespace is available: article unlocks published time, modified time, author and section, and product unlocks price amount and currency. Those extra properties are not decoration, they are the difference between a card that states a price and one that does not.
Numbers worth knowing
| Metric | Typical | What it means |
|---|---|---|
| Recommended og:image | 1200 x 630 (1.91:1) | Fills the large link card exactly. Any other ratio is centre-cropped to fit, which is why logos and text at the edges get cut. |
| Minimum before thumbnail fallback | 600 x 315 | Below this Facebook renders a small square thumbnail next to the text rather than a full-width image, and below roughly 200px a side it renders nothing. |
| Facebook headline cut | around 60 characters | Roughly two lines in feed. Wider on desktop, tighter on a phone with large text, so treat 60 as the number the strictest case survives. |
| X card description | not displayed | A summary_large_image shows the headline as an overlay on the image and no body text in the timeline. Still emit the description for other consumers of the tag. |
| LinkedIn feed preview | title and domain only | No description text in the feed. Whatever has to be read before the click needs to be in the title or the image, not in og:description. |
Mistakes that quietly cost you results
- Using a relative or protocol-relative path in og:image
- Crawlers read the content attribute as a literal URL and do not resolve it against the document, so /img/hero.jpg and //cdn.example.com/hero.jpg both produce an empty preview while looking perfectly correct in the page source.
- Setting og:url to the URL with campaign parameters attached
- Platforms key share counts and engagement to this value, so parameterised variants of one page fragment their own numbers. Set og:url to exactly the string in your rel=canonical and let the tracking live in the link people click.
- Fixing the tags and checking the result by pasting the link into a post
- You are looking at the platform cache, not your markup. Re-scrape the URL in the Sharing Debugger or the Post Inspector first, otherwise you will conclude the fix did not work and go looking for a second bug.
- Shipping one site-wide og:image for every URL
- It is the largest element in the card and the only one doing visual work. A generic brand image makes every share from your site look identical in a feed, which is precisely the situation where a distinct image earns the click.
- Putting the important text at the top or bottom of the image
- X crops the 1.91:1 card closer to 2:1 and every platform crops from the centre. Keep legible content inside a central safe area, and remember the card is often displayed at about a third of its native width.
What does the output look like?
This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.
Frequently asked questions
Do I need the twitter: tags if I already have og: tags?
Only twitter:card, which has no Open Graph equivalent and decides whether you get a full-width image or a small thumbnail. X falls back to og:title, og:description and og:image when the twitter: versions are absent, so duplicating identical values is harmless but pointless. Write the twitter: overrides when you genuinely want a different headline for that audience, and skip them otherwise.
Why does my preview still show the old image after I fixed the tag?
Because the platform cached what it scraped the first time anyone shared the URL, and it keeps serving that copy. Run the URL through Facebook’s Sharing Debugger and click to scrape again, and use LinkedIn’s Post Inspector for the equivalent there. Until you do, pasting the link into a new post shows you the cache rather than your corrected markup.
What image size should I actually use?
Make it 1200 by 630 pixels. That is the 1.91:1 ratio the large card is drawn at, it is large enough for high density screens, and it degrades sensibly everywhere else. Keep legible text in the middle because X crops closer to 2:1, avoid SVG because the crawlers do not render it, and keep the file small enough that a messaging client will bother downloading it.
Does Open Graph markup affect my Google rankings?
No. Google does not use og: tags for ranking and takes its own title and description from the title element, the meta description and the page content. Open Graph governs what happens after someone shares the URL, which is a different traffic source with its own click-through economics. The two jobs are separate, which is why the ideal og:title is often shorter and blunter than the ideal title tag.
What changes when I set og:type to article or product?
Each type unlocks an extra namespace. article adds published time, modified time, author and section, which some readers and aggregators surface. product adds price amount and currency. This tool emits the relevant extra tags with TODO placeholders where it has no value to fill in, so you can see which properties the type makes available rather than discovering them later.
Related free tools
- URL Slug Generator SEO
- Readability Scorer SEO
- SEO Meta Tag Generator for ecommerce product pages SEO
- Cold Email Generator for recruiters Outbound
- Cold Email Generator for saas founders Outbound
Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.