MIME type

A MIME type (Multipurpose Internet Mail Extensions, now formally just “media type” per RFC 6838) is a two-part identifier in the format type/subtype that tells a client what kind of data it’s looking at.

Common examples:

• text/html — HTML document
• application/json — JSON data
• image/png, image/jpeg, image/webp — image formats
• application/pdf — PDF document
• multipart/form-data — file upload payload
• application/octet-stream — opaque binary; the “just bytes, you figure out what it is” fallback

HTTP responses carry MIME types in the Content-Type header. Data URIs (used by our image-to-Base64 tool) embed the MIME type directly: data:image/png;base64,iVBOR.... Browsers use the declared MIME type to decide how to render or download a resource.

Historical note: MIME was originally defined for email attachments. The same registry now defines media types for the web, IM, RSS, and most modern protocols.

The IANA Media Types Registry: every legitimate MIME type is registered with the Internet Assigned Numbers Authority. The top-level types are fixed (text, image, audio, video, application, multipart, message, model, font, example, plus the X- legacy prefix). Subtypes are added through an IETF or vendor-tree registration process; application/vnd.openxmlformats-officedocument.wordprocessingml.document (the formal MIME type for .docx) is a vendor-tree example. Unknown subtypes default to application/octet-stream, which usually triggers a browser download prompt rather than inline rendering.

MIME sniffing — the security gotcha: if a server returns the wrong Content-Type, browsers historically tried to guess from the first bytes of the response. This “content sniffing” allowed cross-site attacks where a user-uploaded image could be reinterpreted as HTML or JavaScript. The fix is X-Content-Type-Options: nosniff, which forces the browser to honour the declared type and refuse to execute mismatched content. Modern web frameworks ship this header by default. Reference: RFC 6838 — Media Type Specifications and Registration Procedures.

Parameters: charset, boundary, profile

A MIME type can carry parameters after a semicolon. The most common is charset: Content-Type: text/html; charset=utf-8 tells the browser the response is HTML encoded as UTF-8. Without it, browsers fall back to legacy encodings (Windows-1252 in many cases) that mangle non-ASCII text. For multipart/form-data uploads, the boundary parameter specifies the delimiter between parts: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW. JSON-LD uses a profile parameter: application/ld+json; profile="https://www.w3.org/ns/activitystreams". Parameters are case-insensitive for names; values are case-insensitive for most well-known parameters but case-sensitive for the multipart boundary.

The +suffix convention

RFC 6839 added a structured-syntax suffix convention that lets new media types declare which generic format they parse as: application/atom+xml, application/vnd.api+json, image/svg+xml. The suffix tells a generic parser (an XML or JSON library) how to read the bytes even if it doesn’t recognise the specific vendor type. Modern web standards rely on this heavily — every JSON-based API media type ends in +json; every XML-based one in +xml. As of 2026 the IANA registry lists more than 2,300 registered media types across all top-level categories, with the application/ tree (1,800+ entries) by far the largest. Reference: IANA Media Types Registry.