MIME types (IANA media types)
A media type (also known as a Multipurpose Internet Mail Extensions or MIME type) is a standard that indicates the nature and format of a document, file, or assortment of bytes. It is defined and standardized in IETF's RFC 6838.
Important: Browsers use the MIME type, not the file
extension, to determine how to process a URL, so it's important that web
servers send the correct MIME type in the response's
header. If this is not correctly configured, browsers are likely to misinterpret the
contents of files and sites will not work correctly, and downloaded files may be
The simplest MIME type consists of a type and a subtype; these
are each strings which, when concatenated with a slash (
/) between them,
comprise a MIME type. No whitespace is allowed in a MIME type:
The type represents the general category into which the
data type falls, such as
subtype identifies the exact kind of data of the specified
type the MIME type represents. For example, for the MIME type
subtype might be
plain (plain text),
(HTML source code), or
Each type has its own set of possible subtypes, and a MIME type always has both a type and a subtype, never just one or the other.
An optional parameter can be added to provide additional details:
For example, for any MIME type whose main type is
text, the optional
charset parameter can be used to specify the character set used for the
characters in the data. If no
charset is specified, the default is
US-ASCII) unless overridden by the user agent's settings. To specify a UTF-8 text file, the MIME type
text/plain;charset=UTF-8 is used.
MIME types are case-insensitive but are traditionally written in lowercase, with the exception of parameter values, whose case may or may not have specific meaning.
There are two classes of type: discrete and multipart. Discrete types are types which represent a single file or medium, such as a single text or music file, or a single video. A multipart type is one which represents a document that's comprised of multiple component parts, each of which may have its own individual MIME type; or, a multipart type may encapsulate multiple files being sent together in one transaction. For example, multipart MIME types are used when attaching multiple files to an email.
The discrete types currently registered with the IANA are:
applicationList at IANA
- Any kind of binary data that doesn't fall explicitly into one of the other types;
either data that will be executed or interpreted in some way or binary data that
requires a specific application or category of application to use. Generic binary data
(or binary data whose true type is unknown) is
application/octet-stream. Other common examples include
audioList at IANA
- Audio or music data. Examples include
- Reserved for use as a placeholder in examples showing how to use MIME types. These
should never be used outside of sample code listings and documentation.
examplecan also be used as a subtype; for instance, in an example related to working with audio on the web, the MIME type
audio/examplecan be used to indicate that the type is a placeholder and should be replaced with an appropriate one when using the code in the real world.
fontList at IANA
- Font/typeface data. Common examples include
imageList at IANA
- Image or graphical data including both bitmap and vector still images as well as
animated versions of still image formats such as animated GIF or APNG.
Common examples are
modelList at IANA
- Model data for a 3D object or scene. Examples include
textList at IANA
- Text-only data including any human-readable content, source code, or textual data
such as comma-separated value (CSV) formatted data. Examples include
videoList at IANA
- Video data or files, such as MP4 movies (
For text documents without a specific subtype,
text/plain should be used.
Similarly, for binary documents without a specific or known subtype,
application/octet-stream should be used.
Multipart types indicate a category of document broken into pieces, often with different MIME types; they can also be used — especially in email scenarios — to represent multiple, separate files which are all part of the same transaction. They represent a composite document.
With the exception of
multipart/form-data, used in
POST method of HTML
multipart/byteranges, used with
Partial Content to send part of a document, HTTP doesn't handle multipart
documents in a special way: the message is transmitted to the browser (which will likely
show a "Save As" window if it doesn't know how to display the document).
There are two multipart types:
messageList at IANA
- A message that encapsulates other messages. This can be used, for instance, to
represent an email that includes a forwarded message as part of its data, or to allow
sending very large messages in chunks as if it were multiple messages. Examples
message/rfc822(for forwarded or replied-to message quoting) and
message/partialto allow breaking a large message into smaller ones automatically to be reassembled by the recipient.
multipartList at IANA
- Data that is comprised of multiple components which may individually have different
MIME types. Examples include
multipart/form-data(for data produced using the
multipart/byteranges(defined in RFC 7233: 5.4.1 and used with HTTP's
206"Partial Content" response returned when the fetched data is only part of the content, such as is delivered using the
This is the default for binary files. As it means unknown binary file,
browsers usually don't execute it, or even ask if it should be executed. They treat it
as if the
Content-Disposition header was set to
attachment, and propose a "Save As" dialog.
This is the default for textual files. Even if it really means "unknown textual file," browsers assume they can display it.
text/plain does not mean "any kind of textual data." If they
expect a specific kind of textual data, they will likely not consider it a match.
Specifically if they download a
text/plain file from a
<link> element declaring a CSS file, they will not recognize it as a
valid CSS file if presented with
text/plain. The CSS mime type
text/css must be used.
CSS files used to style a Web page must be sent with
text/css. If a server doesn't recognize the
.css suffix for
CSS files, it may send them with
application/octet-stream MIME types. If so, they won't be recognized as CSS
by most browsers and will be ignored.
All HTML content should be served with this type. Alternative MIME types for XHTML
application/xhtml+xml) are mostly useless nowadays.
application/xhtml+xml if you want XML’s strict parsing rules,
sections, or elements that aren't from HTML/SVG/MathML namespaces.
of those may result in scripts that do not load or run.
Note: Even though any given user agent may support
any or all of these, you should only use
MIME type guaranteed to work now and into the future.
Some content you find may have a
charset parameter at the end of the
the code's content. This is not valid, and in most cases will result in a script not
Files whose MIME type is
image contain image data. The subtype specifies
which specific image file format the data represents. Only a few image types are used
commonly enough to be considered safe for use on web pages:
|Abbreviation||File format||MIME type||File extension(s)||Summary|
|APNG||Animated Portable Network Graphics||
||Good choice for lossless animation sequences (GIF is less performant). AVIF and WebP have better performance but less broad browser support.
Supported: Chrome, Edge, Firefox, Opera, Safari.
|AVIF||AV1 Image File Format||
Good choice for both images and animated images due to high performance and royalty free image format. It offers much better compression than PNG or JPEG with support for higher color depths, animated frames, transparency etc. Note that when using AVIF, you should include fallbacks to formats with better browser support (i.e. using the
|GIF||Graphics Interchange Format||
||Good choice for simple images and animations. Prefer PNG for lossless and indexed still images, and consider WebP, AVIF or APNG for animation sequences.
Supported: Chrome, Edge, Firefox, IE, Opera, Safari.
|JPEG||Joint Photographic Expert Group image||
Good choice for lossy compression of still images (currently the most popular). Prefer PNG when more precise reproduction of the image is required, or WebP/AVIF if both better reproduction and higher compression are required.
|PNG||Portable Network Graphics||
PNG is preferred over JPEG for more precise reproduction of source images, or when transparency is needed. WebP/AVIF provide even better compression and reproduction, but browser support is more limited.
|SVG||Scalable Vector Graphics||
||Vector image format; ideal for user interface elements, icons, diagrams, etc., that must be drawn accurately at different sizes.
Support: Chrome, Edge, Firefox, IE, Opera, Safari.
|WebP||Web Picture format||
||Excellent choice for both images and animated images. WebP offers much better compression than PNG or JPEG with support for higher color depths, animated frames, transparency etc. AVIF offers slightly better compression, but is not quite as well-supported in browsers and does not support progressive rendering.
Support: Chrome, Edge, Firefox, Opera, Safari
As is the case for images, HTML doesn't mandate that web browsers support any specific
file and codec types for the
elements, so it's important to consider your target audience and the range of browsers
(and versions of those browsers) they may be using when choosing the file type and
codecs to use for media.
Our media container formats guide provides a list of the file types that are commonly supported by web browsers, including information about what their special use cases may be, any drawbacks they have, and compatibility information, along with other details.
The audio codec and video codec guides list the various codecs that web browsers often support, providing compatibility details along with technical information such as how many audio channels they support, what sort of compression is used, and what bit rates and so forth they're useful at. The codecs used by WebRTC guide expands upon this by specifically covering the codecs supported by the major web browsers, so you can choose the codecs that best cover the range of browsers you wish to support.
As for MIME types of audio or video files, they typically specify the container format (file type). The optional codecs parameter can be added to the MIME type to further specify which codecs to use and what options were used to encode the media, such as codec profile, level, or other such information.
The most commonly used MIME types used for web content are listed below. This isn't a complete list of all the types that may be available, however. See the media container formats guide for that.
|MIME type||Audio or video type|
||An audio file in the WAVE container format. The PCM audio codec (WAVE codec "1") is often supported, but other codecs have limited support (if any).|
||An audio file in the WebM container format. Vorbis and Opus are the codecs officially supported by the WebM specification.|
||A video file, possibly with audio, in the WebM container format. VP8 and VP9 are the most common video codecs; Vorbis and Opus the most common audio codecs.|
||An audio file in the Ogg container format. Vorbis is the most common audio codec used in such a container; however, Opus is now supported by Ogg as well.|
||A video file, possibly with audio, in the Ogg container format. Theora is the usual video codec used within it; Vorbis is the usual audio codec, although Opus is becoming more common.|
||An audio or video file using the Ogg container format. Theora is the usual video codec used within it; Vorbis is the usual audio codec.|
multipart/form-data type can be used when sending the values of a
completed HTML Form from browser to
As a multipart document format, it consists of different parts, delimited by a boundary
(a string starting with a double dash
--). Each part is its own entity with
its own HTTP headers,
Content-Type for file uploading fields.
Content-Type: multipart/form-data; boundary=aBoundaryString (other headers associated with the multipart document as a whole) --aBoundaryString Content-Disposition: form-data; name="myFile"; filename="img.jpg" Content-Type: image/jpeg (data) --aBoundaryString Content-Disposition: form-data; name="myField" (data) --aBoundaryString (more subparts) --aBoundaryString--
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data"> <label>Name: <input name="myTextField" value="Test"></label> <label><input type="checkbox" name="myCheckBox"> Check</label> <label>Upload file: <input type="file" name="myFile" value="test.txt"></label> <button>Send the file</button> </form>
will send this message:
POST / HTTP/1.1 Host: localhost:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Upgrade-Insecure-Requests: 1 Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498 Content-Length: 465 -----------------------------8721656041911415653955004498 Content-Disposition: form-data; name="myTextField" Test -----------------------------8721656041911415653955004498 Content-Disposition: form-data; name="myCheckBox" on -----------------------------8721656041911415653955004498 Content-Disposition: form-data; name="myFile"; filename="test.txt" Content-Type: text/plain Simple file. -----------------------------8721656041911415653955004498--
multipart/byteranges MIME type is used to send partial responses to
Partial Content status code is sent, this
MIME type indicates that the document is composed of several parts, one for each of the
requested ranges. Like other multipart types, the
Content-Type uses a
boundary to separate the pieces. Each piece has a
Content-Type header with its actual type and a
Content-Range of the range it represents.
HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5 Content-Length: 385 --3d6b6a416f9b5 Content-Type: text/html Content-Range: bytes 100-200/1270 eta http-equiv="Content-type" content="text/html; charset=utf-8" /> <meta name="vieport" content --3d6b6a416f9b5 Content-Type: text/html Content-Range: bytes 300-400/1270 -color: #f0f0f2; margin: 0; padding: 0; font-family: "Open Sans", "Helvetica --3d6b6a416f9b5--
Most web servers send unrecognized resources as the
application/octet-stream MIME type. For security reasons, most browsers do
not allow setting a custom default action for such resources, forcing the user to save
it to disk to use it.
Some common incorrect server configurations:
RAR-compressed files. In this case, the ideal would be the true type of the original files; this is often impossible as .RAR files can hold several resources of different types. In this case, configure the server to send
Proprietary file types. Avoid using
application/octet-streamas most browsers do not allow defining a default behavior (like "Open in Word") for this generic MIME type. A specific type like
application/vnd.mspowerpointlets users open such files automatically in the presentation software of their choice.
In the absence of a MIME type, or in certain cases where browsers believe they are incorrect, browsers may perform MIME sniffing — guessing the correct MIME type by looking at the bytes of the resource.
Each browser performs MIME sniffing differently and under different circumstances. (For
example, Safari will look at the file extension in the URL if the sent MIME type is
unsuitable.) There are security concerns as some MIME types represent executable
content. Servers can prevent MIME sniffing by sending the
MIME types are not the only way to convey document type information:
- Filename suffixes are sometimes used, especially on Microsoft Windows. Not all operating systems consider these suffixes meaningful (such as Linux and MacOS), and there is no guarantee they are correct.
- Magic numbers. The syntax of different formats allows file-type inference by looking
at their byte structure. For example, GIF files start with the
47 49 46 38 39hexadecimal value (
GIF89), and PNG files with
89 50 4E 47(
.PNG). Not all file types have magic numbers, so this is not 100% reliable either.