meta
elementcharset
attribute is present, or if the element's http-equiv
attribute is in the Encoding declaration state: in a head
element.http-equiv
attribute is present but not in the Encoding declaration state: in a head
element.http-equiv
attribute is present but not in the Encoding declaration state: in a noscript
element that is a child of a head
element.name
attribute is present: where metadata content is expected.name
http-equiv
content
charset
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.
The name
and content
IDL attributes
must reflect the respective content attributes of the
same name. The IDL attribute httpEquiv
must
reflect the content attribute http-equiv
.
This specification defines a few names for the name
attribute of the
meta
element.
Names are case-insensitive.
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.
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.
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:
The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case).
A short non-normative description of what the metadata name's meaning is, including the format the value is required to be in.
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.
One of the following:
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.
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.
State | Keyword | Notes |
---|---|---|
Encoding declaration | content-type
| |
Default style | default-style
| |
Refresh | refresh
|
http-equiv="content-type"
)
The Encoding
declaration state is just an alternative form of setting
the charset
attribute: it is a
character encoding declaration.
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.
http-equiv="default-style"
)
This pragma sets the name of the default alternative style sheet set.
http-equiv="refresh"
)
This pragma acts as timed redirect.
For meta
elements with an http-equiv
attribute in the
Refresh state,
the content
attribute must
have a value consisting either of:
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">
There must not be more than one meta
element with
any particular state in the document at a time.
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:
The actual name being defined. The name must match a previously-registered HTTP name with the same requirements.
A short non-normative description of the purpose of the pragma directive.
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:
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.
In HTML, to declare that the character encoding is UTF-8, the
author could include the following markup near the top of the
document (in the head
element):
<meta charset="utf-8">
In XML, the XML declaration would be used instead, at the very top of the markup:
<?xml version="1.0" encoding="utf-8"?>