Complete List of MIME Types

MIME types explained

What is a MIME type?

A MIME type (also called a media type or content type) is a short string that identifies the format of a document or a piece of data, independently of its file name. The name comes from Multipurpose Internet Mail Extensions, the e-mail standard where it was introduced in 1992 (RFC 2045/2046) to describe attachments; the same labels were then adopted by HTTP, HTML and almost every other Internet protocol.

A media type is made of a type and a subtype separated by a slash, optionally followed by parameters:

type/subtype
type/subtype; parameter=value

text/html; charset=UTF-8
multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxk
application/vnd.openxmlformats-officedocument.wordprocessingml.document

• Type — the broad category. The registered top-level types are application, audio, font, image, message, model, multipart, text and video (example is reserved for documentation, haptics was added in 2024).
• Subtype — the specific format. Registration trees are visible in the name: vnd. for vendor-specific formats (application/vnd.ms-excel), prs. for personal ones, and structured-syntax suffixes such as +xml, +json or +zip that tell a generic parser what the underlying syntax is (image/svg+xml, application/problem+json).
• Parameters — optional attributes. The most common is charset on text types; boundary is mandatory for multipart/*, and codecs refines audio and video types (video/mp4; codecs="avc1.42E01E").

Type and subtype names are case-insensitive, but they are traditionally written in lower case. Parameters values may be case-sensitive depending on the parameter.

Where are MIME types used?

• HTTP — the Content-Type response header tells the browser how to interpret the body; the Accept request header lists the types a client can handle (Accept: application/json), and Content-Type on a request describes the payload you send (application/x-www-form-urlencoded, multipart/form-data, application/json).
• E-mail — every MIME part of a message carries a Content-Type; attachments are usually application/octet-stream plus a file name in Content-Disposition.
• HTML — the type attribute of <script>, <style>, <link>, <source>, <object> and <embed>; the accept attribute of file inputs (accept="image/*,.pdf"); the enctype of forms; and the <meta http-equiv="Content-Type"> tag.
• JavaScript — Blob and File objects have a type property, fetch() and XMLHttpRequest expose the response type, and data URLs embed it directly: data:image/png;base64,….
• Databases and storage — object stores such as S3 keep the content type as metadata so that the file is served correctly later.

How web servers map file extensions to MIME types

A static web server does not inspect the bytes of a file: it looks at the file extension and consults a mapping table.

• Apache ships a conf/mime.types file (one line per type followed by its extensions, e.g. image/png png) loaded by mod_mime. You can add or override entries with the AddType directive in httpd.conf or in a .htaccess file: AddType application/wasm .wasm. The ForceType and DefaultType directives exist for special cases.
• Nginx uses the types { … } block in mime.types (included from nginx.conf) and default_type application/octet-stream; for anything unknown.
• IIS keeps the table in applicationHost.config (<staticContent><mimeMap fileExtension=".json" mimeType="application/json" />) and lets you edit it per site in the "MIME Types" feature of IIS Manager or in web.config. IIS refuses to serve files whose extension is not mapped (HTTP 404.3).
• Application frameworks (Express, Django, Spring, ASP.NET Core…) embed their own tables, usually derived from the mime-db project or Apache's file.

This is why an extension that is not in the table is served as application/octet-stream (download) or text/plain, and why the mapping must be kept in sync with new formats such as .webp, .avif, .woff2, .wasm or .mjs.

Registration by IANA

Media types are registered with the Internet Assigned Numbers Authority (IANA) following the procedures of RFC 6838. The standards tree (application/json) requires an RFC or a standards-body specification; the vendor tree (vnd.) only needs a registration form; the personal tree (prs.) is for experimental or private use. The registry currently holds well over 2,000 entries. Many widely used types were never registered at all (application/x-www-form-urlencoded is defined by the HTML standard, image/webp was only registered in 2024), which is why lists compiled from Apache and browsers, like this one, are usually more practical than the registry alone.

Common MIME types

The "x-" prefix

Historically, unregistered or experimental types were given an x- prefix: application/x-gzip, image/x-png, text/x-markdown, audio/x-wav. The idea was that a type could be used privately before registration and renamed later. In practice the "experimental" names never went away, so RFC 6648 (2012) deprecated the convention: new types should be registered directly under their final name, and software should treat the x- variants that still exist as aliases (application/x-gzip = application/gzip, audio/x-wav = audio/wav). You will still meet the old spellings in server configurations and in the list above; prefer the registered name whenever both exist.

Content sniffing and X-Content-Type-Options: nosniff

When a server sends a missing or implausible Content-Type, browsers historically "sniffed" the first bytes of the response to guess the real format (the rules are standardised in the WHATWG MIME Sniffing specification). Sniffing is convenient but dangerous: a text file that a user uploaded could be reinterpreted as HTML and executed as script on your domain (a classic cross-site scripting vector), or a JSON response could be treated as JavaScript.

The response header X-Content-Type-Options: nosniff disables this guessing: the browser must use the declared type, blocks stylesheets and scripts whose type is wrong, and does not render responses as HTML unless they say so. Send it on every response together with an accurate Content-Type, and serve user uploads from a separate origin (or with Content-Disposition: attachment) for defense in depth.

Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff

Choosing the right type for an unknown file

1. Look up the extension in the table above (the Lookup by file extension box does exactly that).
2. If several types exist, prefer the one without an x- prefix and, when both an IANA-registered and a vendor name exist, the registered one.
3. If nothing matches, use application/octet-stream for binary data and text/plain; charset=UTF-8 for text, and add the extension to your server's mapping when you control it.