A media type (also
MIME type and content type) is a two-part
identifier for file formats and format contents transmitted on the
1.1 Common examples 1.2 Registration trees
1.2.1 Standards tree 1.2.2 Vendor tree 1.2.3 Personal or Vanity tree 1.2.4 Unregistered x. tree
2 Mailcap 3 mime.types
4 See also 5 References 6 External links
A media type is composed of a type, a subtype, and optional
As an example, an
All media types should be registered using the IANA registration
procedures. For the efficiency and flexibility of the media type
registration process, different structures of sub-type names can be
registered in registration "trees" that are distinguished by the use
of faceted names, e.g. sub-type names that begin with a "tree." prefix
(facet). Currently the following trees are created: standard, vendor,
personal or vanity, unregistered "x.". These registration trees were
first defined in November 1996 (obsoleted RFC 2048 - currently RFC
6838). New registration trees may be created by IETF Standards Action
- for external registration and management by well-known permanent
organizations (e.g. scientific societies).
Media types in the standards tree do not use any tree facet
Registrations in the standards tree must be either associated with
IETF specifications approved directly by the IESG, or registered by an
IANA recognized standards-related organization.
type / media type name [+suffix]
Examples: "application/xhtml+xml", "image/png"
Vendor tree is used for media types associated with publicly available
products. It uses vnd. facet.
The terms "vendor" and "producer" are considered equivalent in the
context. Industry consortia as well as non-commercial entities can
register media types in the vendor tree. A registration in the vendor
tree may be created by anyone who needs to interchange files
associated with some software product or set of products. However, the
registration belongs to the vendor or organization producing the
software that employs the type being registered, and that vendor or
organization can at any time elect to assert ownership of a
registration done by a third party.
type / vnd. media type name [+suffix] - used in the case of well-known
type / vnd. producer's name followed by media type name [+suffix] -
producer's name must be approved by IANA
type / vnd. producer's name followed by product's name [+suffix] -
producer's name must be approved by IANA
Personal or Vanity tree
Personal or Vanity tree includes media types created experimentally or
as part of products that are not distributed commercially. It uses
type / prs. media type name [+suffix]
Unregistered x. tree
The "x." tree may be used for media types intended exclusively for use
in private, local environments and only with the active agreement of
the parties exchanging them. Types in this tree cannot be registered.
According to RFC 6838 (published in January 2013), any use of types in
the "x." tree is strongly discouraged. Media types with names
beginning with "x-" are no longer considered to be members of this
tree since January 2013.
According to the previous version of RFC 6838 - obsoleted RFC 2048
(published in November 1996) it should rarely, if ever, be necessary
to use unregistered experimental types, and as such use of both "x-"
and "x." forms is discouraged. Previous versions of that RFC - RFC
1590 and RFC 1521 stated that the use of "x-" notation for the
sub-type name may be used for unregistered and private sub-types, but
this recommendation was obsoleted in November 1996 by RFC 2048.
All media types should be registered using the simplified IANA
registration procedures for vendor and personal trees or using the
standards procedure for standards tree.
Media types that have been widely deployed (with an unfaceted sub-type
name beginning with the "x-" prefix) without being registered, should
be, if possible, re-registered with a proper faceted sub-type name. If
this is not possible, the media type can, after an approval by both
the media types reviewer and the IESG, be registered in the proper
tree with its unfaceted name.
type / x. media type name [+suffix]
Suffix is an augmentation to the media type definition to additionally
specify the underlying structure of that media type. Media types that
make use of a named structured syntax should use the appropriate IANA
registered "+suffix" for that structured syntax when they are
registered. Unregistered suffixes should not be used (since January
2013). Structured syntax suffix registration procedures are defined in
RFC 6838.
The currently registered suffixes are: (in RFC 6839) +xml, +json,
+ber, +der, +fastinfoset, +wbxml, +zip, (in RFC 7049) +cbor
+xml suffix is defined since January 2001 (RFC 3023). Formal
registration of +xml suffix and other suffixes is defined since
January 2013 (RFC 6839).
Mailcap (derived from the phrase "mail capability") is a type of meta
file used to configure how MIME-aware applications such as mail
clients and web browsers render files of different MIME-types. The
mailcap format is defined by RFC1524 "A User Agent Configuration
Mechanism for Multimedia Mail Format Information) but is not defined
text/html htm html
This article is missing information about the Shared MIME-info standard.. Please expand the article to include this information. Further details may exist on the talk page. (August 2016)
Content negotiation Content sniffing XML and MIME
^ "Content-Type: text". Exchange Server 2003 documentations.
Microsoft. 8 June 2004. Retrieved 29 December 2015.
^ Freed, N.; Borenstein, N. (November 1996). "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of
IANA list of official media types The Python Standard Library mailcap Mailcap f