What Is a MIME Type? A Developer's Guide to Media Types

A MIME type is a short, standardized string that tells software what kind of data a file or message body contains, such as text/html or image/png. It is the label that lets a browser, email client, or API know whether to render a page, display an image, or trigger a download, regardless of the file's name or extension.

What MIME type actually means

MIME stands for Multipurpose Internet Mail Extensions. It was first defined in the early 1990s and is specified today across RFC 2045 and RFC 2046, which let email carry more than plain ASCII text, including images, audio, and attachments with different character sets. The same labeling system was adopted by HTTP, and it now identifies content everywhere data moves between programs.

Because the term is used far beyond email today, the official name for these strings is now media type. You will see both "MIME type" and "media type" used interchangeably; they refer to the exact same thing. The authoritative list of registered values is maintained by IANA, and the registration procedures are defined in RFC 6838.

How the type/subtype format works

Every media type has the form type/subtype. The first part is a broad category and the second part names the specific format within it. A few common top-level types:

• text — human-readable text, e.g. text/plain, text/html, text/css
• image — e.g. image/png, image/jpeg, image/svg+xml
• audio and video — e.g. audio/mpeg, video/mp4
• application — arbitrary binary or structured data, e.g. application/json, application/pdf, application/zip
• multipart — a body composed of several parts, e.g. multipart/form-data for file uploads

A media type can carry optional parameters after a semicolon. The most important is charset, which states the character encoding. For example, text/html; charset=utf-8 tells the browser to decode the bytes as UTF-8. Without a correct charset, text can render as garbled characters (mojibake).

Two conventions are worth knowing. Subtypes prefixed with vnd. are vendor-specific (for example application/vnd.ms-excel), and a +suffix indicates an underlying structured syntax — image/svg+xml and application/ld+json signal that the data is XML and JSON respectively.

Where MIME types show up

The most common place a developer meets a media type is the HTTP Content-Type response header. When a server sends a page, it includes a line like Content-Type: text/html; charset=utf-8, and the browser uses that to decide how to handle the bytes. You can inspect the headers a real URL returns with an HTTP Header Inspector.

Media types appear in several other places too:

• Request bodies — when a client POSTs data, its Content-Type tells the server how to parse it, commonly application/json or application/x-www-form-urlencoded.
• The Accept header — a client sends Accept: application/json to request a specific format through content negotiation.
• Data URLs — the scheme embeds the media type inline, as in data:image/png;base64,iVBOR.... You can build these with a Data URL Creator, and they often pair with Base64 encoding.
• HTML attributes — <script type="module">, <source type="video/mp4">, and <link type> all use media types.

How servers and browsers decide the type

On the server side, the media type is usually chosen by file extension. Web servers such as Nginx and Apache ship with a mapping table (often mime.types) that pairs each extension with a media type. If an extension is missing from that table, the server frequently falls back to application/octet-stream, a generic "unknown binary" type that browsers treat as a download.

Browsers do not blindly trust the declared type. When a response looks suspicious or carries a generic type, a browser may run MIME sniffing — inspecting the first bytes of the content to guess the real format. This behavior is standardized by the WHATWG MIME Sniffing specification. Sniffing is convenient but historically a security risk, because a file declared as text could be sniffed and executed as HTML or script.

Common pitfalls and how to avoid them

A handful of mistakes account for most media-type bugs:

• Wrong or missing Content-Type. Serving JSON as text/plain can make a client refuse to parse it; serving an SVG as text/plain stops it from rendering. Always set the type that matches the bytes. You can confirm the correct value for any extension with a MIME Type Lookup.
• Missing charset on text. For text-based types, include ; charset=utf-8 so non-ASCII characters decode correctly. Modern guidance is to use UTF-8 everywhere.
• Relying on sniffing for security. Send the header X-Content-Type-Options: nosniff so browsers honor your declared type instead of guessing. This is a standard defense against content-type-confusion attacks on user-uploaded files.
• Confusing the extension with the type. A file named report.pdf is not automatically a PDF — the bytes determine the real format, and an attacker can rename anything. Validate uploads by their actual content, not their filename.
• Using a non-standard type. Inventing text/json instead of the registered application/json can cause clients to mishandle the response. Prefer values from the IANA registry.

A practical quick reference

These are the media types developers reach for most often:

When you are working with JSON specifically, declaring application/json and validating the payload structure go hand in hand; a JSON Formatter helps confirm the body is well-formed before you ship it. Getting the media type right is a small detail that quietly determines whether your content renders, downloads, parses, or breaks.

Frequently Asked Questions