Security & devFreeNo signup
Google publishes the list of meta tags it actually uses, and it is short: description, robots and googlebot, notranslate, nopagereadaloud, google-site-verification, content-type and charset, refresh, viewport, rating. Until 6 October 2026 the default output of the box above included a robots value that is not on Google's list of valid rules at all; the box now writes no robots tag unless you pick a real one. Here is what each tag the generator writes is for, which specification defines it, and which ones change nothing.
Last updated 6 October 2026
These tags are written by four different authorities. <title> and <link rel="canonical"> come from the HTML standard; what Google does with description and robots is Google's own documented behaviour; og: belongs to the Open Graph protocol; twitter: belongs to a convention whose specification is no longer publicly published. The output looks like one block of markup and it is four, with four different levels of evidence behind it. That is what the sections below separate.
Every page about meta descriptions gives a length. 150 characters, 155, 160, sometimes 920 pixels. Google gives none: There's no limit on how long a meta description can be, but the snippet is truncated in Google Search results as needed, typically to fit the device width.
Read that twice, because it replaces a character count with a measurement in a different unit. Truncation happens by rendered width, on the device the reader is holding. A description of 160 narrow characters and one of 160 wide ones cut in different places, and the same description cuts in two different places on a phone and a laptop. There is no single number that can be correct, which is why the authority that would have to publish one does not.
The counter under the description field on this page calls anything over 160 characters long for many SERPs
and anything under 50 short
. Both thresholds are conventions of the SEO trade. Neither comes from Google, and nothing on this page should be read as implying they do.
The second thing worth knowing is that writing a description does not get you that description. Google: Google sometimes uses the meta description HTML element if it might give users a more accurate description of the page than content taken directly from the page.
The tag is a candidate. Google picks between it and text it extracts from the page, and the way to win that comparison is to describe what is specifically on the page rather than restate the title.
One tag the generator correctly does not write is keywords. Google is categorical: The meta-keyword tag is not used by Google Search, and it has no effect on indexing and ranking at all.
The Robots dropdown used to default to index,follow, and the generator wrote the tag on every run whatever you picked, because the line that emitted it was unconditional. So until 6 October 2026 the default output of this page always contained:
<meta name="robots" content="index,follow">
Google's documented list of valid indexing and serving rules is all, noindex, nofollow, none, nosnippet, indexifembedded, max-snippet, max-image-preview, max-video-preview, notranslate, noimageindex and unavailable_after. index and follow do not appear on it.
The permissive state has a name, and it is all, which Google describes as: There are no restrictions for indexing or serving. This rule is the default value and has no effect if explicitly listed.
A page with no robots meta tag is already in that state. Writing index,follow asks for the default using two words that are not on Google's list at all, so the effect is the same as omitting the tag.
That is what the dropdown now does. Its first option writes no robots tag, which is the permissive state spelled correctly, and the status line says so rather than leaving you to wonder why a tag you expected is absent. The generator also filters whatever it is given against the list above, so a token that is not a rule is dropped and named rather than emitted.
The other three options are a different matter. noindex and nofollow are real rules with real effects, and noindex is the correct tool for keeping a page out of results. The one trap to carry away: a noindex only works if the crawler is allowed to fetch the page and read it. Google states that For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.
If you also disallow the URL in robots.txt, you have hidden the instruction you wanted obeyed. The Robots.txt Generator page sets out that interaction in full.
Two things Google says about rel="canonical". The field above now enforces the first and cannot enforce the second.
It should be an absolute URL. Use absolute paths rather than relative paths with the rel="canonical" link element.
The stated reason is not pedantry: Even though relative paths are supported by Google, they can cause problems in the long run (for example, if you unintentionally allow your testing site to be crawled) and thus we don't recommend them.
A relative canonical resolves against whatever host serves it, so a staging copy of the page declares the staging URL canonical.
The Canonical URL field is an HTML url input, and until 6 October 2026 the generator read its value without checking validity. Typing example.com produced <link rel="canonical" href="example.com">, a relative path pointing at a directory called example.com, and the same unchecked value went into og:url as well. The generator now parses the value and requires a scheme of http or https and a host. A value that fails produces neither tag, and the status line quotes it back with the reason, because a canonical silently pointing at the wrong place is worse than no canonical.
And the tag does not compel anything. Google calls it A strong signal that the specified URL should become canonical
. Google weighs it against redirects, internal linking, sitemaps and the rest, and can choose a different canonical. Treat a mismatch in Search Console as a disagreement to investigate rather than as a bug in the tag.
Open Graph is a published specification with a short, hard requirement at the top: The four required properties for every page are
og:title, og:type, og:image and og:url.
Three of those the generator always produces from fields that are filled in by default. The fourth, og:image, is the only one of the four a reader is likely to leave blank. Until 6 October 2026 its field was labelled optional, which the specification plainly contradicts; the label now says the protocol requires it, and leaving it blank makes the status line name what is missing. Nothing stops you generating the tags without it, because an incomplete head is sometimes what you want, but you are told. In practice this is the difference between a link that unfurls with a picture and one that does not.
The specification also asks for alt text: If the page specifies an og:image it should specify og:image:alt
, defined as A description of what is in the image (not a caption)
. Until 6 October 2026 this generator never wrote that tag under any circumstances, so filling in the image field gave you og:image with nothing beside it. There is now a field for the alt text, and the tag is written when both are filled. Supply an image and no alt text and the status line asks for it, quoting the protocol's own distinction between a description and a caption.
One detail that is easy to get wrong by hand and that the generator does get right: Open Graph tags use the property attribute, not name. <meta name="og:title"> is a common mistake and is not what the protocol defines.
This is the part of the output with the weakest evidence behind it, and saying so is more useful than pretending otherwise.
The generator writes twitter:card, twitter:title, twitter:description and, if you supply an image, twitter:image. These come from the Twitter Cards convention. On 2 October 2026 we went looking for the specification that defines which of those tags each card type requires, in particular whether summary_large_image requires an image. The documented markup page returned HTTP 402 Payment Required, and the address now redirects to a general developer documentation index with no card markup reference behind it.
So we are not going to tell you what X requires, because we could not read it. What can be said from the generator's own behaviour is that selecting summary_large_image and leaving the image field empty produces a card declaration with no image to put in it, which is at best pointless. If the large-image card is what you want, fill in the image field.
The practical consequence is that the Open Graph tags are the ones worth getting right. They are defined by a specification that is still published and readable, and several platforms fall back to them.
A generator that writes HTML from text you type has to escape that text, or a quotation mark in a product name silently breaks the tag it sits in. We ran the page's own escaping function against the characters that matter. It escapes ampersand, double quote and less-than, in that order, which is the correct order because escaping the ampersand first prevents double-escaping everything after it.
| Typed into a field | What the meta tag contains |
|---|---|
Acme " Store | content="Acme " Store" |
x"><script> | content="x"><script>" |
Jack & Jill | content="Jack & Jill" |
a > b | content="a > b" |
The second row is the one that matters. A value crafted to close the attribute and open a script tag does not do so: the quote becomes an entity and the tag never closes early. The fourth row shows greater-than passing through unescaped, which is correct rather than sloppy, because a bare greater-than is valid both inside a double-quoted attribute value and in element text.
The title line behaves differently on purpose. It escapes the value and then turns " back into a plain quotation mark, because inside a <title> element a quotation mark is ordinary text and does not need escaping. Less-than stays escaped there, so a typed </title> cannot close the element early. We tested that case too.
Two input caps are worth knowing about because nothing explains them on screen: the title field stops accepting text at 120 characters and the description field at 300. Neither figure comes from any specification cited on this page, and as noted above Google publishes no limit at all.
It cannot see your page. Every tag it writes is a claim about content it has never read, and a description that does not match the page is the most common reason Google writes its own snippet instead.
It does not check that anything exists. The canonical URL is checked for shape, so a relative path is refused, but nothing here fetches anything: the image URL and the site name are copied through as typed, and a misspelled image URL still produces a perfectly well-formed tag pointing at nothing.
It does not write everything a page needs. There is no og:locale, no charset, no viewport, no language attribute and no structured data. The output is a starting block for the head of a document, not a complete head.
And it cannot tell you whether any of this will change how you rank. None of these tags is a ranking input in the sense people usually mean. Description and the social tags affect what a result or a shared link looks like; the robots rules affect whether a page is eligible to appear at all. Neither is a substitute for the page being worth returning.
all is the default value and has no effect if explicitly listed.Every quotation above was read on 2 October 2026 from the page named. The escaping table was produced by extracting the generator's own escaping function from this page's source and running it against those inputs, not by reasoning about what it ought to do. The Twitter Cards markup specification is deliberately absent from this list: it was sought on the same date and could not be read, as described above, and nothing here is asserted about what X requires. Part of the QuikUtil tools collection.
Google gives no number, and the 150 to 160 characters repeated everywhere is not its figure. The documentation says There's no limit on how long a meta description can be, but the snippet is truncated in Google Search results as needed, typically to fit the device width.
Truncation is by rendered width on the reader's screen, not by a character count, so the same description cuts at different points on a phone and a desktop. The counter under the description box here flags anything over 160 as long, which is a convention rather than a sourced threshold.
No. Google's list of valid indexing and serving rules contains all, noindex, nofollow, none, nosnippet, indexifembedded, max-snippet, max-image-preview, max-video-preview, notranslate, noimageindex and unavailable_after. index and follow are not on it. The permissive default is all, and Google says of it: This rule is the default value and has no effect if explicitly listed.
Until 6 October 2026 the generator emitted the robots tag on every run, so its default output carried a line that did nothing. It now writes the tag only when you choose a rule that is actually on Google's list, and the status line says when it has written none.
Sometimes. Google sometimes uses the meta description HTML element if it might give users a more accurate description of the page than content taken directly from the page.
It is an input to the snippet, not the snippet. A description that merely repeats the title gives Google no reason to prefer it over the page text.
Yes, and until 6 October 2026 this page's own field label said optional, which understated it. The Open Graph protocol states that The four required properties for every page are
og:title, og:type, og:image and og:url. Leave the image field empty here and the output is missing one of the four, which the status line now says in those words. The protocol also asks for alt text, If the page specifies an og:image it should specify og:image:alt
, and until 6 October 2026 this generator never wrote that tag at all. There is now a field for it.
Yes. Google: Use absolute paths rather than relative paths with the rel="canonical" link element.
Its reason is practical rather than theoretical: Even though relative paths are supported by Google, they can cause problems in the long run (for example, if you unintentionally allow your testing site to be crawled) and thus we don't recommend them.
Until 6 October 2026 the URL field did not enforce it, so typing example.com produced <link rel="canonical" href="example.com">, which resolves as a relative path. The generator now refuses a value that is not an absolute http or https URL, writes neither the canonical nor og:url from it, and says what was wrong. Note too that canonical is A strong signal that the specified URL should become canonical
, a signal rather than an instruction.
No. We tested it against the page's own escaping function. Ampersand, double quote and less-than are all escaped before the value is written into an attribute, so x"><script> comes out as content="x"><script>" and cannot break out of the attribute. Greater-than is left unescaped, which is valid inside a double-quoted attribute value and in element text. The title line un-escapes the quote again, correctly, because a raw quotation mark is ordinary text inside a title element.
Because it does nothing. Google: The meta-keyword tag is not used by Google Search, and it has no effect on indexing and ranking at all.
Its absence from this tool is correct.
They are generated on the historic Twitter Cards convention, and we could not source them. The developer documentation that defined twitter:card and twitter:image is no longer publicly readable at its old address: requests to the card markup page returned HTTP 402 Payment Required, and following the link redirects to a general documentation index with no card markup page behind it. So nothing on this page states what X requires for a given card type. The Open Graph tags beside them are defined by a specification that is still published, which is the better thing to get right.