Open Access Articles- Top Results for Internet media type

Internet media type

An Internet media type[1] is a standard identifier used on the Internet to indicate the type of data that a file contains. Common uses include the following:

  • 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.

IANA manages the official registry of media types.

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.

Their use has expanded from email sent through SMTP, to other protocols such as HTTP, RTP and SIP.

New media types can be created with the procedures outlined in RFC 6838.


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 an 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/zip instead 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.[1]: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.[2][3]

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.[4][5] Advanced content sniffing approaches have been proposed to balance interoperability and security in such situations.[3]


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""[6]

Registration trees

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).

Standards tree

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

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/", "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.

The currently registered suffixes are: (in RFC 6839) +xml, +json, +ber, +der, +fastinfoset, +wbxml, +zip, (in RFC 7049) +cbor[7]

"+xml" suffix is defined since January 2001 (RFC 3023). Formal registration of "+xml" suffix and other suffixes is defined since January 2013 (RFC 6839).

List of common media types

IANA manages the official registry of media types. Among others, it includes the following types:

Type application

For Multipurpose files:

  • application/atom+xml: Atom feeds
  • application/vnd.dart: Dart files [8]
  • application/ecmascript: ECMAScript/JavaScript; Defined in RFC 4329 (equivalent to application/javascript but with stricter processing rules)
  • application/EDI-X12: EDI X12 data; Defined in RFC 1767
  • application/EDIFACT: EDI EDIFACT data; Defined in RFC 1767
  • application/json: JavaScript Object Notation JSON; Defined in RFC 4627
  • application/javascript: ECMAScript/JavaScript; Defined in RFC 4329 (equivalent to application/ecmascript but with looser processing rules) It is not accepted in IE 8 or earlier - text/javascript is accepted but it is defined as obsolete in RFC 4329. The "type" attribute of the <script> tag in HTML5 is optional. In practice, omitting the media type of JavaScript programs is the most interoperable solution, since all browsers have always assumed the correct default even before HTML5.
  • application/octet-stream: Arbitrary binary data.[9] 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.[10]
  • application/ogg: Ogg, a multimedia bitstream container format; Defined in RFC 5334
  • application/dash+xml: MPEG-DASH, a multimedia streaming standard
  • 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-woff until 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/xop+xml: XOP
  • application/zip: ZIP archive files; Registered[11]
  • 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)

For Multimedia files:

Type audio

For Audio.

Type example

For example types in documentation, not for real code.

Type image

Type message

Type model

For 3D models.

Type multipart

For archives and other objects made of more than one part.

Type text

For human-readable text and source code.

Type video

For video.

List of common media subtype prefixes

Prefix vnd

For vendor-specific files.

  • application/ For download apk files.
  • application/vnd.debian.binary-package: deb (file format), a software package format used by the Debian project; Registered[19]
  • application/ KML files (e.g. for Google Earth)[20]
  • application/ KMZ files (e.g. for Google Earth)[21]
  • application/vnd.mozilla.xul+xml: Mozilla XUL files
  • application/ Microsoft Excel files
  • application/ Microsoft Powerpoint files
  • application/ XPS document[22]
  • application/vnd.oasis.opendocument.text: OpenDocument Text; Registered[23]
  • application/vnd.oasis.opendocument.spreadsheet: OpenDocument Spreadsheet; Registered[24]
  • application/vnd.oasis.opendocument.presentation: OpenDocument Presentation; Registered[25]
  • application/ OpenDocument Graphics; Registered[26]
  • application/vnd.openxmlformats-officedocument.spreadsheetml.sheet: Microsoft Excel 2007 files
  • application/vnd.openxmlformats-officedocument.presentationml.presentation: Microsoft Powerpoint 2007 files
  • application/vnd.openxmlformats-officedocument.wordprocessingml.document: Microsoft Word 2007 files
  • text/ ABC music notation; Registered[16]

Prefix x

For experimental or non-standard files. Deprecated by RFC 6648.[27]

  • application/x-7z-compressed: 7-Zip compression format.
  • application/x-chrome-extension: Google Chrome/Chrome OS extension, app, or theme package [28]
  • 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-javascript:
  • 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
  • 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

See also


  1. ^ a b "Internet Media Type registration, consistency of use". W3C. 2002-09-04. Retrieved 2012-02-29. 
  2. ^ "MIME Type Detection in Windows Internet Explorer". Microsoft. Retrieved 2012-07-14. 
  3. ^ a b Gordon P. Hemsley, Adam Barth, Ian Hickson (29 November 2012). "MIME Sniffing Standard, Living Standard". Retrieved 2013-08-16. 
  4. ^ "CVE-2008-5343 (under review)". MITRE Corporation. 4 December 2008. Retrieved 1 January 2013. 
  5. ^ Henry Sudhof (11 February 2009). "Risky sniffing: MIME sniffing in Internet Explorer enables cross-site scripting attacks". The H. Retrieved 2012-07-14. 
  6. ^ The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types, 2011-08  Check date values in: |date= (help)
  7. ^ Structured Syntax Suffix Registry, 2012-07-20 
  8. ^ "Embedding Dart in HTML". Retrieved 2013-12-03. 
  9. ^ RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media types. Retrieved on 2010-09-29.
  10. ^ "RFC 7231: Content-Type". HTTP/1.1 Semantics and Content. The Internet Society. June 2014. Retrieved 2014-07-31. 
  11. ^ MIME SUBTYPE NAME: zip
  12. ^ "Supported Media Formats". RealPlayer Help. RealNetworks. 2010. Retrieved 28 May 2012. 
  13. ^ MIME SUBTYPE NAME: png
  14. ^ the premier menu for djvu resources. Retrieved on 2015-02-12.
  15. ^ vnd.a
  16. ^ a b
  17. ^ Mime Types List
  18. ^ Quicktime
  19. ^ vnd.debian.binary-package
  20. ^ "Application Media Types". IANA. Retrieved 2012-02-19. 
  21. ^ "KML Tutorial - Keyhole Markup Language — Google Developers". Retrieved 2013-08-16. 
  22. ^ "MIME Type". Retrieved 2013-08-16. 
  23. ^ vnd.oasis.opendocument.text
  24. ^ vnd.oasis.opendocument.spreadsheet
  25. ^ vnd.oasis.opendocument.presentation
  26. ^
  27. ^ "RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols". IETF. June 2012. Retrieved 2012-10-07. 
  28. ^ Hosting - Google Chrome. (2013-08-02). Retrieved on 2015-02-12.

External links