HTML5

4.2.5 The meta element

Categories:

Metadata content.

Contexts in which this element can be used:

If the charset attribute is present, or if the element's http-equiv attribute is in the Encoding declaration state: in a head element.

If the http-equiv attribute is present but not in the Encoding declaration state: in a head element.

If the http-equiv attribute is present but not in the Encoding declaration state: in a noscript element that is a child of a head element.

If the name attribute is present: where metadata content is expected.

Content model:

Empty.

Content attributes:

Global attributes

name

http-equiv

content

charset

DOM interface:

interface HTMLMetaElement : HTMLElement {
           attribute DOMString name;
           attribute DOMString httpEquiv;
           attribute DOMString content;
};

The meta element represents various kinds of metadata that cannot be expressed using the title, base, link, style, and script elements.

The meta element can represent document-level metadata with the name attribute, pragma directives with the http-equiv attribute, and the file's character encoding declaration when an HTML document is serialized to string form (e.g. for transmission over the network or for disk storage) with the charset attribute.

Exactly one of the name, http-equiv, and charset attributes must be specified.

If either name or http-equiv is specified, then the content attribute must also be specified. Otherwise, it must be omitted.

The charset attribute specifies the character encoding used by the document. This is a character encoding declaration. If the attribute is present in an XML document, its value must be an ASCII case-insensitive match for the string "UTF-8" (and the document is therefore forced to use UTF-8 as its encoding).

The charset attribute on the meta element has no effect in XML documents, and is only allowed in order to facilitate migration to and from XHTML.

There must not be more than one meta element with a charset attribute per document.

The content attribute gives the value of the document metadata or pragma directive when the element is used for those purposes. The allowed values depend on the exact context, as described in subsequent sections of this specification.

If a meta element has a name attribute, it sets document metadata. Document metadata is expressed in terms of name-value pairs, the name attribute on the meta element giving the name, and the content attribute on the same element giving the value. The name specifies what aspect of metadata is being set; valid names and the meaning of their values are described in the following sections. If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

4.2.5.1 Standard metadata names

This specification defines a few names for the name attribute of the meta element.

Names are case-insensitive, and must be compared in an ASCII case-insensitive manner.

application-name

The value must be a short free-form string giving the name of the Web application that the page represents. If the page is not a Web application, the application-name metadata name must not be used. There must not be more than one meta element with its name attribute set to the value application-name per document. User agents may use the application name in UI in preference to the page's title, since the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.

author

The value must be a free-form string giving the name of one of the page's authors.

description

The value must be a free-form string that describes the page. The value must be appropriate for use in a directory of pages, e.g. in a search engine. There must not be more than one meta element with its name attribute set to the value description per document.

generator

The value must be a free-form string that identifies one of the software packages used to generate the document. This value must not be used on hand-authored pages.

Here is what a tool called "Frontweaver" could include in its output, in the page's head element, to identify itself as the tool used to generate the page:

<meta name=generator content="Frontweaver 8.2">

keywords

The value must be a set of comma-separated tokens, each of which is a keyword relevant to the page.

This page about typefaces on British motorways uses a meta element to specify some keywords that users might use to look for the page:

<!DOCTYPE HTML>
<html>
 <head>
  <title>Typefaces on UK motorways</title>
  <meta name="keywords" content="british,type face,font,fonts,highway,highways">
 </head>
 <body>
  ...

Many search engines do not consider such keywords, because this feature has historically been used unreliably and even misleadingly as a way to spam search engine results in a way that is not helpful for users.

To obtain the list of keywords that the author has specified as applicable to the page, the user agent must run the following steps:

1. Let keywords be an empty list.

2. For each meta element with a name attribute and a content attribute and whose name attribute's value is keywords, run the following substeps:

   1. Split the value of the element's content attribute on commas.

   2. Add the resulting tokens, if any, to keywords.

3. Remove any duplicates from keywords.

4. Return keywords. This is the list of keywords that the author has specified as applicable to the page.

User agents should not use this information when there is insufficient confidence in the reliability of the value.

For instance, it would be reasonable for a content management system to use the keyword information of pages within the system to populate the index of a site-specific search engine, but a large-scale content aggregator that used this information would likely find that certain users would try to game its ranking mechanism through the use of inappropriate keywords.

4.2.5.2 Other metadata names

Extensions to the predefined set of metadata names may be registered in the WHATWG Wiki MetaExtensions page. [WHATWGWIKI]

Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type. These new names must be specified with the following information:

Keyword

The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case).

Brief description

A short non-normative description of what the metadata name's meaning is, including the format the value is required to be in.

Specification

A link to a more detailed description of the metadata name's semantics and requirements. It could be another page on the Wiki, or a link to an external page.

Synonyms

A list of other names that have exactly the same processing requirements. Authors should not use the names defined to be synonyms, they are only intended to allow user agents to support legacy content. Anyone may remove synonyms that are not used in practice; only names that need to be processed as synonyms for compatibility with legacy content are to be registered in this way.

Status

One of the following:

Proposed

The name has not received wide peer review and approval. Someone has proposed it and is, or soon will be, using it.

Ratified

The name has received wide peer review and approval. It has a specification that unambiguously defines how to handle pages that use the name, including when they use it in incorrect ways.

Discontinued

The metadata name has received wide peer review and it has been found wanting. Existing pages are using this metadata name, but new pages should avoid it. The "brief description" and "specification" entries will give details of what authors should use instead, if anything.

If a metadata name is found to be redundant with existing values, it should be removed and listed as a synonym for the existing value.

If a metadata name is registered in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the registry.

If a metadata name is added with the "proposed" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added with the "proposed" status and found to be harmful, then it should be changed to "discontinued" status.

Anyone can change the status at any time, but should only do so in accordance with the definitions above.

Metadata names whose values are to be URLs must not be proposed or accepted. Links must be represented using the link element, not the meta element.

4.2.5.3 Pragma directives

When the http-equiv attribute is specified on a meta element, the element is a pragma directive.

The http-equiv attribute is an enumerated attribute. The following table lists the keywords defined for this attribute. The states given in the first cell of the rows with keywords give the states to which those keywords map. Some of the keywords are non-conforming, as noted in the last column.

Content language state (http-equiv="content-language")

This feature is non-conforming. Authors are encouraged to use the lang attribute instead.

This pragma sets the pragma-set default language. Until the pragma is successfully processed, there is no pragma-set default language.

1. If another meta element with an http-equiv attribute in the Content Language state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.

2. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

3. If the element's content attribute contains a "," (U+002C) character then abort these steps.

4. Let input be the value of the element's content attribute.

5. Let position point at the first character of input.

6. Skip whitespace.

7. Collect a sequence of characters that are not space characters.

8. Let the pragma-set default language be the string that resulted from the previous step.

This pragma is not exactly equivalent to the HTTP Content-Language header. [HTTP]

Encoding declaration state (http-equiv="content-type")

The Encoding declaration state is just an alternative form of setting the charset attribute: it is a character encoding declaration. This state's user agent requirements are all handled by the parsing section of the specification.

For meta elements with an http-equiv attribute in the Encoding declaration state, the content attribute must have a value that is an ASCII case-insensitive match for a string that consists of: the literal string "text/html;", optionally followed by any number of space characters, followed by the literal string "charset=", followed by the character encoding name of the character encoding declaration.

A document must not contain both a meta element with an http-equiv attribute in the Encoding declaration state and a meta element with the charset attribute present.

The Encoding declaration state may be used in HTML documents, but elements with an http-equiv attribute in that state must not be used in XML documents.

Default style state (http-equiv="default-style")

This pragma sets the name of the default alternative style sheet set.

1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

2. Set the preferred style sheet set to the value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

1. If another meta element with an http-equiv attribute in the Refresh state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.

2. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

3. Let input be the value of the element's content attribute.

4. Let position point at the first character of input.

5. Skip whitespace.

6. Collect a sequence of characters in the range ASCII digits, and parse the resulting string using the rules for parsing non-negative integers. If the sequence of characters collected is the empty string, then no number will have been parsed; abort these steps. Otherwise, let time be the parsed number.

7. Collect a sequence of characters in the range ASCII digits and "." (U+002E). Ignore any collected characters.

8. Skip whitespace.

9. Let url be the address of the current page.

10. If the character in input pointed to by position is a ";" (U+003B), then advance position to the next character. Otherwise, jump to the last step.

11. Skip whitespace.

12. If the character in input pointed to by position is a "U" (U+0055) character or a "u" (U+0075) character, then advance position to the next character. Otherwise, jump to the last step.

13. If the character in input pointed to by position is a "R" (U+0052) character or a "r" (U+0072) character, then advance position to the next character. Otherwise, jump to the last step.

14. If the character in input pointed to by position is s "L" (U+004C) character or a "l" (U+006C) character, then advance position to the next character. Otherwise, jump to the last step.

15. Skip whitespace.

16. If the character in input pointed to by position is a "=" (U+003D), then advance position to the next character. Otherwise, jump to the last step.

17. Skip whitespace.

18. If the character in input pointed to by position is either a "'" (U+0027) character or """ (U+0022) character, then let quote be that character, and advance position to the next character. Otherwise, let quote be the empty string.

19. Let url be equal to the substring of input from the character at position to the end of the string.

20. If quote is not the empty string, and there is a character in url equal to quote, then truncate url at that character, so that it and all subsequent characters are removed.

21. Strip any trailing space characters from the end of url.

22. Strip any "tab" (U+0009), "LF" (U+000A), and "CR" (U+000D) characters from url.

23. Resolve the url value to an absolute URL, relative to the meta element. If this fails, abort these steps.

24. Perform one or more of the following steps:

    • After the refresh has come due (as defined below), if the user has not canceled the redirect and if the meta element's Document's browsing context did not have the sandboxed automatic features browsing context flag set when the Document was created, navigate the Document's browsing context to url, with replacement enabled, and with the Document's browsing context as the source browsing context.

      For the purposes of the previous paragraph, a refresh is said to have come due as soon as the later of the following two conditions occurs:

      • At least time seconds have elapsed since the document has completely loaded, adjusted to take into account user or user agent preferences.
      • At least time seconds have elapsed since the meta element was inserted into the Document, adjusted to take into account user or user agent preferences.

    • Provide the user with an interface that, when selected, navigates a browsing context to url, with the document's browsing context as the source browsing context.

    • Do nothing.

    In addition, the user agent may, as with anything, inform the user of any and all aspects of its operation, including the state of any timers, the destinations of any timed redirects, and so forth.

For meta elements with an http-equiv attribute in the Refresh state, the content attribute must have a value consisting either of:

• just a valid non-negative integer, or
• a valid non-negative integer, followed by a ";" (U+003B) character, followed by one or more space characters, followed by a substring that is an ASCII case-insensitive match for the string "URL", followed by a "=" (U+003D) character, followed by a valid URL that does not start with a literal "'" (U+0027) or """ (U+0022) character.

In the former case, the integer represents a number of seconds before the page is to be reloaded; in the latter case the integer represents a number of seconds before the page is to be replaced by the page at the given URL.

A news organization's front page could include the following markup in the page's head element, to ensure that the page automatically reloads from the server every five minutes:

<meta http-equiv="Refresh" content="300">

A sequence of pages could be used as an automated slide show by making each page refresh to the next page in the sequence, using markup such as the following:

<meta http-equiv="Refresh" content="20; URL=page4.html">

Cookie setter (http-equiv="set-cookie")

This pragma sets an HTTP cookie. [COOKIES]

It is non-conforming. Real HTTP headers should be used instead.

1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

2. Obtain the storage mutex.

3. Act as if receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the value of the element's content attribute encoded as UTF-8. [COOKIES] [RFC3629]

There must not be more than one meta element with any particular state in the document at a time.

4.2.5.4 Other pragma directives

Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page. [WHATWGWIKI]

Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header. [IANAPERMHEADERS]

Pragma directives corresponding to headers describing metadata, or not requiring specific user agent processing, must not be registered; instead, use metadata names. Pragma directives corresponding to headers that affect the HTTP processing model (e.g. caching) must not be registered, as they would result in HTTP-level behavior being different for user agents that implement HTML than for user agents that do not.

Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions. Such registrations must specify the following information:

Keyword

The actual name being defined. The name must match a previously-registered HTTP name with the same requirements.

Brief description

A short non-normative description of the purpose of the pragma directive.

Specification

A link to the specification defining the corresponding HTTP header.

4.2.5.5 Specifying the document's character encoding

A character encoding declaration is a mechanism by which the character encoding used to store or transmit a document is specified.

The following restrictions apply to character encoding declarations:

• The character encoding name given must be the name of the character encoding used to serialize the file.
• The value must be a valid character encoding name, and must be an ASCII case-insensitive match for the preferred MIME name for that encoding. [IANACHARSET]
• The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
• The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document.

In addition, due to a number of restrictions on meta elements, there can only be one meta-based character encoding declaration per document.

If an HTML document does not start with a BOM, and if its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the character encoding used must be an ASCII-compatible character encoding, and, in addition, if that encoding isn't US-ASCII itself, then the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state.

If the document is an iframe srcdoc document, the document must not have a character encoding declaration. (In this case, the source is already decoded, since it is part of the document that contained the iframe.)

If an HTML document contains a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state, then the character encoding used must be an ASCII-compatible character encoding.

Authors are encouraged to use UTF-8. Conformance checkers may advise authors against using legacy encodings. [RFC3629]

Encodings in which a series of bytes in the range 0x20 to 0x7E can encode characters other than the corresponding characters in the range U+0020 to U+007E represent a potential security vulnerability: a user agent that does not support the encoding (or does not support the label used to declare the encoding, or does not use the same mechanism to detect the encoding of unlabelled content as another user agent) might end up interpreting technically benign plain text content as HTML tags and JavaScript. For example, this applies to encodings in which the bytes corresponding to "<script>" in ASCII can encode a different string. Authors should not use such encodings, which are known to include JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), encodings based on ISO-2022, and encodings based on EBCDIC. Furthermore, authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings, which also fall into this category, because these encodings were never intended for use for Web content. [RFC1345] [RFC1842] [RFC1468] [RFC2237] [RFC1554] [CP50220] [RFC1922] [RFC1557] [CESU8] [UTF7] [BOCU1] [SCSU]

Authors should not use UTF-32, as the encoding detection algorithms described in this specification intentionally do not distinguish it from UTF-16. [UNICODE]

Using non-UTF-8 encodings can have unexpected results on form submission and URL encodings, which use the document's character encoding by default.

In XHTML, the XML declaration should be used for inline character encoding information, if necessary.

<meta charset="utf-8">

<?xml version="1.0" encoding="utf-8"?>