Internet media type
- email clients use them to identify attachment files,
- web browsers use them to determine how to display or output files that are not in HTML format,
- search engines use them to classify data files on the web.
A media type is composed of a type, a subtype, and zero or more optional parameters. As an example, an HTML file might be designated
text/html; charset=UTF-8. In this example
text is the type,
html is the subtype, and
charset=UTF-8 is an optional parameter indicating the character encoding.
The identifiers were originally defined in RFC 2046, and were called MIME types because they referred to the non-ASCII parts of email messages that were composed using the MIME (Multipurpose Internet Mail Extensions) specification. They are also sometimes referred to as Content-types.
New media types can be created with the procedures outlined in RFC 6838.
- 1 Limitations
- 2 Naming
- 3 List of common media types
- 4 List of common media subtype prefixes
- 5 See also
- 6 References
- 7 External links
Internet media types are often used as part of a communication protocol between two applications (the source and destination). In this context, internet media type specifiers experience several problems.
The first problem is the ability of the source application (i.e. web server, email client) to correctly determine an internet media type for a piece of content. Many applications attempt to heuristically classify a file using its filename extension or with magic numbers. Neither approach is perfect, and may incorrectly classify a content's media type:
- Incorrect filename extension: a filename extension classifier will report an incorrect media type. For instance, some applications incorrectly give Rich text format files the .doc file extensions, instead of the correct .rtf extension.
- No filename extension: a filename extension classifier will report no media type, or will (incorrectly) report a catch-all type such as
application/octet-stream. Files without extension are common on unix systems.
- Filename extension collisions: when multiple formats use the same filename extension, a filename extension classifier will choose one media type arbitrarily. For instance, both Microsoft Word templates and graphviz graph files use the extension .dot.
- Ambiguous container formats: a magic number classifier may give a correct, though non-specific, media type, thus preventing a meaningful interpretation of the content. For instance, Office Open XML (.docx) format and Java executable (.jar) are both implemented internally as a zipped archive. A magic number system may classify such files as
application/zipinstead of the more specific type. Similar problems occur between XML and application formats implemented on top of XML.
- Ambiguous magic numbers: an attacker can create a file which is identified simultaneously as two separate internet media types. For instance, the internal structure of a Gifar makes it both a valid GIF image and Java executable.
The second problem is the destination application's ability to trust the internet media type reported by the sender. As above, the internet media type is incorrect in some circumstances, and must be treated with skepticism. As early as 2002, the W3C unambiguously warned that it is a "serious error" if internet media type is incorrect, and that software should not attempt to guess a correct media type.:Section 2 Nonetheless, software engineering principles encourage software that forgives a certain degree of malformed input, and user experience suffers when software fails to correctly interpret the content. Consequently, the many destination applications are designed to attempt recovery from such errors and identify a correct media type.
The destination application has no more knowledge of the content than the source application, and attempts to infer the media type at the destination are equally difficult. This can lead to incompatibilities between source and destination applications, and in the worst-case, security vulnerabilities such as the Gifar attack or Cross-site scripting attacks. Advanced content sniffing approaches have been proposed to balance interoperability and security in such situations.
Media type consists of top-level type name and subtype name, which is further structured into so-called "trees". Media types can optionally define companion data, known as parameters.
top-level type name / subtype name [ ; parameters ]
top-level type name / [ tree. ] subtype name [ +suffix ] [ ; parameters ]
The currently registered top-level type names are: application, audio, example, image, message, model, multipart, text, video.
Subtype name typically consists of a media type name, but it may or must also contain other content, such as tree prefix (facet), producer's name, product name or suffix - according the different rules in registration trees.
Examples: "image/svg+xml", "application/vnd.oasis.opendocument.text", "text/plain; charset=utf-8", "video/mp4; codecs="avc1.640028""
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 subtype names can be registered in registration "trees" that are distinguished by the use of faceted names, e.g. subtype 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 (prefix).
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 producer
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
Examples: "application/vnd.ms-excel", "application/vnd.oasis.opendocument.text" for OASIS OpenDocument Text, "application/vnd.etsi.asic-s+zip" for ETSI ASiC
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 "prs." facet.
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 subtype name may be used for unregistered and private subtypes, but this recommendation was obsoleted in November 1996.
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 subtype name beginning with the "x-" prefix) without being registered, should be, if possible, reregistered with a proper faceted subtype 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.
List of common media types
For Multipurpose files:
application/atom+xml: Atom feeds
application/dart: Dart files 
application/EDI-X12: EDI X12 data; Defined in RFC 1767
application/EDIFACT: EDI EDIFACT data; Defined in RFC 1767
application/ecmascriptbut with looser processing rules) It is not accepted in IE 8 or earlier -
application/octet-stream: Arbitrary binary data. Generally speaking this type identifies files that are not associated with a specific application. Contrary to past assumptions by software packages such as Apache this is not a type that should be applied to unknown files. In such a case, a server or application should not indicate a content type, as it may be incorrect, but rather, should omit the type in order to allow the recipient to guess the type.
application/ogg: Ogg, a multimedia bitstream container format; Defined in RFC 5334
application/pdf: Portable Document Format, PDF has been in use for document exchange on the Internet since 1993; Defined in RFC 3778
application/postscript: PostScript; Defined in RFC 2046
application/rdf+xml: Resource Description Framework; Defined by RFC 3870
application/rss+xml: RSS feeds
application/soap+xml: SOAP; Defined by RFC 3902
application/font-woff: Web Open Font Format; (candidate recommendation; use
application/x-font-woffuntil standard is official)
application/xhtml+xml: XHTML; Defined by RFC 3236
application/xml: XML files; Defined by RFC 3023
application/xml-dtd: DTD files; Defined by RFC 3023
application/zip: ZIP archive files; Registered
application/gzip: Gzip, Defined in RFC 6713
application/example: example in documentation, Defined in RFC 4735
application/x-nacl: Native Client web module (supplied via Google Web Store only)
application/x-pnacl: Portable Native Client web module (may supplied by any website as it is safer than x-nacl)
audio/basic: μ-law audio at 8 kHz, 1 channel; Defined in RFC 2046
audio/L24: 24bit Linear PCM audio at 8–48 kHz, 1-N channels; Defined in RFC 3190
audio/mp4: MP4 audio
audio/mpeg: MP3 or other MPEG audio; Defined in RFC 3003
audio/ogg: Ogg Vorbis, Speex, Flac and other audio; Defined in RFC 5334
audio/opus: Opus audio
audio/vorbis: Vorbis encoded audio; Defined in RFC 5215
audio/vnd.rn-realaudio: RealAudio; Documented in RealPlayer Help
audio/vnd.wave: WAV audio; Defined in RFC 2361
audio/webm: WebM open media format
audio/example: example in documentation, Defined in RFC 4735
For example types in documentation, not for real code.
example:Defined in RFC 4735
image/gif: GIF image; Defined in RFC 2045 and RFC 2046
image/jpeg: JPEG JFIF image; Defined in RFC 2045 and RFC 2046
image/pjpeg: JPEG JFIF image; Associated with Internet Explorer; Listed in ms775147(v=vs.85) - Progressive JPEG, initiated before global browser support for progressive JPEGs (Microsoft and Firefox).
image/png: Portable Network Graphics; Registered, Defined in RFC 2083
image/svg+xml: SVG vector image; Defined in SVG Tiny 1.2 Specification Appendix M
image/vnd.djvu: DjVu image and multipage document format.
image/example: example in documentation, Defined in RFC 4735
message/http: Defined in RFC 7230
message/imdn+xml: IMDN Instant Message Disposition Notification; Defined in RFC 5438
message/partial: Email; Defined in RFC 2045 and RFC 2046
message/rfc822: Email; EML files, MIME files, MHT files, MHTML files; Defined in RFC 2045 and RFC 2046
message/example: example in documentation, Defined in RFC 4735
For 3D models.
model/iges: IGS files, IGES files; Defined in RFC 2077
model/mesh: MSH files, MESH files; Defined in RFC 2077, SILO files
model/vrml: WRL files, VRML files; Defined in RFC 2077
model/x3d+binary: X3D ISO standard for representing 3D computer graphics, X3DB binary files - never Internet Assigned Numbers Authority approved
model/x3d+fastinfoset: X3D ISO standard for representing 3D computer graphics, X3DB binary files (application in process, this replaces any use of
model/x3d-vrml: X3D ISO standard for representing 3D computer graphics, X3DV VRML files (application in process, previous uses may have been
model/x3d+xml: X3D ISO standard for representing 3D computer graphics, X3D XML files
model/example: example in documentation, Defined in RFC 4735
For archives and other objects made of more than one part.
multipart/mixed: MIME Email; Defined in RFC 2045 and RFC 2046
multipart/alternative: MIME Email; Defined in RFC 2045 and RFC 2046
multipart/related: MIME Email; Defined in RFC 2387 and used by MHTML (HTML mail)
multipart/form-data: MIME Webform; Defined in RFC 2388
multipart/signed: Defined in RFC 1847
multipart/encrypted: Defined in RFC 1847
multipart/example: example in documentation, Defined in RFC 4735
text/cmd: commands; subtype resident in Gecko browsers like Firefox 3.5
text/css: Cascading Style Sheets; Defined in RFC 2318
text/csv: Comma-separated values; Defined in RFC 4180
text/example: example in documentation, Defined in RFC 4735
text/html: HTML; Defined in RFC 2854
<script>tag in HTML5 is optional and there is no need to use it at all since all browsers have always assumed the correct default (even in HTML 4 where it was required by the specification).
text/plain: Textual data; Defined in RFC 2046 and RFC 3676
text/rtf: RTF; Defined by Paul Lindner
text/vcard: vCard (contact information); Defined in RFC 6350
text/vnd.abc: ABC music notation; Registered
text/xml: Extensible Markup Language; Defined in RFC 3023
video/avi: Covers most Windows-compatible formats including .avi and .divx
video/example: example in documentation, Defined in RFC 4735
video/mpeg: MPEG-1 video with multiplexed audio; Defined in RFC 2045 and RFC 2046
video/mp4: MP4 video; Defined in RFC 4337
video/ogg: Ogg Theora or other video (with audio); Defined in RFC 5334
video/quicktime: QuickTime video; Registered
video/webm: WebM Matroska-based open media format
video/x-matroska: Matroska open media format
video/x-ms-wmv: Windows Media Video; Documented in Microsoft KB 288102
video/x-flv: Flash video (FLV files)
List of common media subtype prefixes
For vendor-specific files.
application/vnd.debian.binary-package: deb (file format), a software package format used by the Debian project; Registered
application/vnd.oasis.opendocument.text: OpenDocument Text; Registered
application/vnd.oasis.opendocument.spreadsheet: OpenDocument Spreadsheet; Registered
application/vnd.oasis.opendocument.presentation: OpenDocument Presentation; Registered
application/vnd.oasis.opendocument.graphics: OpenDocument Graphics; Registered
application/vnd.ms-excel: Microsoft Excel files
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet: Microsoft Excel 2007 files
application/vnd.ms-powerpoint: Microsoft Powerpoint files
application/vnd.openxmlformats-officedocument.presentationml.presentation: Microsoft Powerpoint 2007 files
application/vnd.openxmlformats-officedocument.wordprocessingml.document: Microsoft Word 2007 files
application/vnd.mozilla.xul+xml: Mozilla XUL files
application/vnd.google-earth.kml+xml: KML files (e.g. for Google Earth)
application/vnd.google-earth.kmz: KMZ files (e.g. for Google Earth)
application/vnd.android.package-archive: For download apk files.
application/vnd.ms-xpsdocument: XPS document
text/vnd.abc: ABC music notation; Registered
application/x-7z-compressed: 7-Zip compression format.
application/x-chrome-extension: Google Chrome/Chrome OS extension, app, or theme package 
application/x-dvi: device-independent document in DVI format
application/x-font-ttf: TrueType Font No registered MIME type, but this is the most commonly used
application/x-latex: LaTeX files
application/x-mpegURL: .m3u8 variant playlist
application/x-rar-compressed: RAR archive files
application/x-shockwave-flash: Adobe Flash files for example with the extension .swf
application/x-stuffit: StuffIt archive files
application/x-tar: Tarball files
application/x-www-form-urlencoded: Form Encoded Data; Documented in HTML 4.01 Specification, Section 184.108.40.206
application/x-xpinstall: Add-ons to Mozilla applications (Firefox, Thunderbird, SeaMonkey, and the discontinued Sunbird)
audio/x-aac: .aac audio files
audio/x-caf: Apple's CAF audio files
image/x-xcf: GIMP image file
text/x-gwt-rpc: GoogleWebToolkit data
text/x-jquery-tmpl: jQuery template data
text/x-markdown: Markdown formatted text
application/x-pkcs12: a variant of PKCS standard files
- "Internet Media Type registration, consistency of use". W3C. 2002-09-04. Retrieved 2012-02-29.
- "MIME Type Detection in Windows Internet Explorer". Microsoft. Retrieved 2012-07-14.
- Gordon P. Hemsley, Adam Barth, Ian Hickson (29 November 2012). "MIME Sniffing Standard, Living Standard". Mimesniff.spec.whatwg.org. Retrieved 2013-08-16.
- "CVE-2008-5343 (under review)". MITRE Corporation. 4 December 2008. Retrieved 1 January 2013.
- Henry Sudhof (11 February 2009). "Risky sniffing: MIME sniffing in Internet Explorer enables cross-site scripting attacks". The H. Retrieved 2012-07-14.
- The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types, 2011-08
- Structured Syntax Suffix Registry, 2012-07-20
- "Embedding Dart in HTML". Dartlang.org. Retrieved 2013-12-03.
- RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media types. Tools.ietf.org. Retrieved on 2010-09-29.
- "RFC 7231: 220.127.116.11. Content-Type". HTTP/1.1 Semantics and Content. The Internet Society. June 2014. Retrieved 2014-07-31.
- MIME SUBTYPE NAME: zip
- "Supported Media Formats". RealPlayer Help. RealNetworks. 2010. Retrieved 28 May 2012.
- MIME SUBTYPE NAME: png
- Mime Types List
- "Application Media Types". IANA. Retrieved 2012-02-19.
- "KML Tutorial - Keyhole Markup Language — Google Developers". Developers.google.com. Retrieved 2013-08-16.
- "MIME Type". Social.msdn.microsoft.com. Retrieved 2013-08-16.
- "RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols". IETF. June 2012. Retrieved 2012-10-07.