Skip to content
Free Tool Arena

How-To & Life · Guide · Developer Utilities

How to look up MIME types

Common MIME types by extension, multipart types, charset parameter, registering custom types, and debugging Content-Type mismatches.

Updated April 2026 · 6 min read

MIME types — Multipurpose Internet Mail Extensions, now officially called “media types” — label a byte stream so the receiver knows what it is. Served in the Content-Type HTTP response header, stamped on every file upload, and handed around by the operating system for file-open dialogs, they decide whether your browser renders, downloads, or rejects the bytes. The format is simple: type/subtype, optionally with parameters. The registry behind it is maintained by IANA and holds thousands of entries. Getting the type wrong causes quiet bugs — images fail to render, JSON downloads instead of parsing, fonts fail silently in Firefox. This guide covers the structure of a MIME type, the common types you will actually meet, how IANA assignment works, file-extension mapping, the security implications of X-Content-Type-Options: nosniff, and why browsers sniff when you let them.

Advertisement

Structure of a media type

The general form is type/subtype;parameter=value. Example: text/html; charset=utf-8.

Top-level type is one of a fixed set: application, audio, example, font, image, message, model, multipart, text, video.

Subtype identifies the specific format: html, json, png.

Parameters add context — charset for text, boundary for multipart, profile for linked-data JSON.

Prefixes on subtypes signal status: x- was the pre-2012 convention for unregistered types (application/x-custom), now deprecated in favor of vnd. for vendor-specific, and prs. for personal use.

Structured syntax suffixes

A + in the subtype indicates a format built on a common syntax. Examples:

application/ld+json — JSON-LD, JSON with linked-data semantics.

image/svg+xml — SVG, which is XML.

application/atom+xml — Atom feed, also XML.

Parsers that recognize the base syntax (+json, +xml, +cbor, +zip) can fall back to generic handling if they do not know the specific type.

Common types you meet weekly

text/html — HTML documents.

text/css, text/javascript— stylesheets and scripts. (Historically application/javascript; IANA now recommends text/javascript.)

application/json — JSON. Note: application, not text, and no charset parameter by spec (JSON is defined as UTF-8).

application/xml, text/xml — XML. Either works but application/xml is the RFC 7303 recommendation for machine-consumed XML.

image/jpeg (not jpg), image/png, image/gif, image/webp, image/avif, image/svg+xml.

application/pdf, application/zip, application/octet-stream (unknown binary).

font/woff2 (since 2017; previously application/font-woff2), font/woff, font/ttf.

multipart/form-data — HTML file uploads. Includes a boundary= parameter the server needs to split the parts.

application/x-www-form-urlencoded — standard HTML form submissions without files.

The IANA registry

Every officially recognized media type is registered with IANA at iana.org/assignments/media-types. The registry has four assignment trees:

Standards tree: common, no prefix (application/json).

Vendor tree: vnd. prefix (application/vnd.ms-excel, application/vnd.google-earth.kml+xml).

Personal tree: prs. prefix, for personal or experimental types.

Unregistered tree: x. prefix for private use. Legacy types used x- without the dot (application/x-shockwave-flash) and most are grandfathered in.

Registering a new type is a short form plus a public review. For API authors: do not invent application/my-custom-thing; use application/vnd.acme.thing+json so it inherits JSON’s handling in generic clients.

File extension mapping

MIME type and file extension are two ways of saying the same thing, and the mapping is almost always in a shared system table. On Linux /etc/mime.types; on Apache mime.types; Node.js has the mime package; every language ecosystem ships one.

Some types have multiple valid extensions: image/jpeg.jpg, .jpeg, .jpe. One extension can have multiple valid types depending on content: .ogg might be audio or video. Never deduce type from extension alone for user uploads — check the actual bytes.

Content-Type and charset

For text-based types, always include the charset: Content-Type: text/html; charset=utf-8. Without it, browsers guess, which can cause mojibake — “é” showing up as “é” — when bytes are interpreted in the wrong encoding.

For binary types, no charset is meaningful. Including one (image/png; charset=utf-8) is harmless but nonsensical and worth cleaning up.

MIME sniffing and nosniff

Browsers historically sniff the first few hundred bytes of a response and override the declared Content-Typeif they disagree. This helped with mislabeled servers but opened a security hole: an attacker uploads a file labeled text/plain that browsers sniff as HTML and execute scripts from.

The defense is the header X-Content-Type-Options: nosniff, which tells the browser “trust my Content-Type, do not sniff.” Send it on every response. Combined with correct types, it neutralizes a whole class of cross-site scripting attacks.

Always send nosniff on user uploads and attachments. Combine with Content-Disposition: attachment to force download for types that browsers would otherwise render.

Wildcards in Accept

The Accept request header uses media types with wildcards and quality values (q-factors):

Accept: text/html,application/xhtml+xml,
        application/xml;q=0.9,
        image/webp,image/avif,*/*;q=0.8

*/* matches anything; image/* matches any image. q is a preference weight from 0 to 1, default 1. The server picks the most preferred type it can produce.

MIME for streaming and chunked content

Live-streaming formats have their own types:

application/vnd.apple.mpegurl (HLS playlist).

application/dash+xml (DASH manifest).

text/event-stream (Server-Sent Events).

For WebSocket, the initial upgrade is HTTP with application/octet-stream-ish payloads, but WebSocket itself does not use Content-Type per message.

Common mistakes

Serving JSON as text/plain. Many clients (fetch, XHR) will still parse it on response.json(), but CORS preflights and content filters key off the declared type. Always declare application/json.

Serving JS as text/html. Older CDN misconfigurations. Modern browsers with nosniff will refuse to execute, breaking your app. Check the Content-Type in dev tools.

Trusting user-declared type on upload. A user renaming malware.exe to image.png and claiming image/png is trivial. Read the first bytes (“magic numbers”) to verify.

Omitting charset on HTML. Leads to encoding guesses that vary by browser. Always declare charset=utf-8.

Using application/octet-stream as a lazy default. Forces browsers to download rather than render. Acceptable for true binary blobs; annoying for actual text or images.

Invented types. application/x-my-widget-v2. Use the vendor tree with a structured-syntax suffix: application/vnd.mycompany.widget-v2+json.

Run the numbers

Look up any type or extension instantly with the MIME type lookup. Pair with the HTTP status code lookup when Content-Type and response code both need diagnosing, and the user agent parser for content-negotiation debugging where UA and Accept interact.

Advertisement

Found this useful?Email