Meta Tag Generator
Build SEO, Open Graph and Twitter Card tags with a live Google, Facebook and Twitter preview β auto-synced so you're not retyping the same title and description three times. Export as HTML or a ready Next.js metadata object. Runs entirely in your browser.
Writing Tags That Get Clicked, Not Just Indexed
- Write the title for a human scanning a results page, not a keyword list. A title that reads as a natural phrase outperforms one stuffed with repeated terms, and Google has gotten noticeably better at penalizing the latter over the years.
- Keep the description close to 150-160 characters, not far under it. A short description leaves free real estate in the search snippet that Google will often fill in with its own extracted text instead β text you don't control.
- Use a 1200Γ630px image for Open Graph, not a square one. That aspect ratio is what Facebook, LinkedIn and Twitter's large-image card all expect; a square or portrait image gets cropped unpredictably by each platform's own algorithm.
- Set canonical even on pages with no obvious duplicate. Tracking parameters, trailing slashes, and www-vs-non-www variants create accidental duplicates more often than most sites realize.
Features
A Preview Catches What Reading the Code Never Will
Reading a list of <meta> tags and mentally reconstructing what a search result or a shared link will actually look like is a genuinely unreliable way to check the work β a title that's three characters over the practical limit, a description that reads fine as isolated text but sounds robotic once placed under a bold blue headline, an Open Graph image that's the right file but the wrong aspect ratio, are all things that are obvious the moment they're rendered and easy to miss in raw markup. Rendering an actual Google-style result, an actual Facebook-style card, and an actual Twitter-style card from the same data being typed is what catches those problems before a page ships, not after a link gets shared and someone notices it looks wrong.
website Isn't the Only Open Graph Type Worth Knowing
og:type does more than fill in a required field β Facebook and LinkedIn both use it to decide which additional metadata a scraper should look for on the page. website, the default here, is the right choice for the overwhelming majority of pages and asks for nothing beyond the standard fields. article unlocks a small set of article-specific tags β a published date, an author byline β that a richer card renderer can pick up and display alongside the title and image, which is worth the switch for a blog post or news piece specifically, even though this generator focuses on the core fields rather than every article-specific extension. Getting the type right costs nothing and occasionally buys a noticeably richer card; getting it wrong just means a scraper looks for fields that were never going to be there and quietly ignores them.
Escaping Isn't Optional, Even for a Meta Tag
A meta description containing a straight quote β a page about "best practices" in a title, for instance β will silently break a naively-generated <meta> tag, since an unescaped quote inside a double-quoted HTML attribute ends the attribute early and leaves everything after it interpreted as raw, unintended markup. This is a real, common failure mode for hand-written or poorly-generated meta tags, not a theoretical edge case β any title or description containing a quotation mark, an apostrophe rendered as a curly quote, or an ampersand needs proper entity escaping to generate valid HTML. Every field here is escaped correctly before being placed into an attribute or the page title, so content with quotes, ampersands, or angle brackets in it never produces broken markup.
The two escaping rules aren't identical, either, which is exactly the kind of detail a hand-written generator tends to get inconsistently right. Attribute values β everything sitting inside content="..." β need quotes escaped specifically, since that's the character that terminates the attribute early. The page <title> element's text content isn't an attribute at all, so the character that actually matters there is a literal < sign, which could otherwise be misread as the start of a new tag. Applying the same escaping function everywhere works safely either way, but it's worth knowing the two failure modes are genuinely different problems being solved by the same fix.
Three Copies of the Same Sentence Is a Maintenance Problem
A page genuinely needing three meaningfully different descriptions β one for the meta description, a separate one for Open Graph, a third for Twitter β is rare in practice; most real sites intentionally use the same core copy across all three, because the audience reading a shared Twitter card and the audience reading a Google result are being sold the same page for the same reason. Auto-sync exists specifically for that common case: leave a field empty and it inherits from the layer above it β Twitter from Open Graph, Open Graph from the primary tags β while typing anything into a specific field overrides just that one value immediately. The practical effect is writing the core title and description once, then only touching the social fields for the genuinely rare cases where a platform-specific version is actually warranted.
It also quietly prevents a specific kind of drift that shows up months after a page first ships: someone updates the meta description to reflect a product change, but the Open Graph and Twitter versions β typed separately, in a different part of the same form or a different file entirely β never get touched, and a shared link keeps showing outdated copy long after the page itself has moved on. With sync active, updating the one field that actually needs updating propagates everywhere it should, unless that specific social field was deliberately customized in the first place.
From Filled-In Fields to Shipped Markup
A typical path: write the primary title and description first, since everything else in Auto Sync mode cascades from those two fields, then add an Open Graph image and check all three preview tabs before touching anything else β a surprising number of issues are visible in the preview alone, well before the raw HTML matters. For a Next.js project, exporting directly as the metadata object skips the error-prone step of hand-translating a block of HTML tags into the framework's specific object shape; for anything else, the plain HTML export drops straight into a page's <head>. Pairing this with a correctly configured robots.txt file covers both halves of how a page presents itself to search engines and how it's allowed to be crawled in the first place β one controls what gets shown once a page is found, the other controls whether it gets found and indexed at all, and neither one substitutes for the other.