MIME: Multipurpose Internet Mail Extensions

When you click a link that downloads a PDF, your browser doesn't peek inside the file to figure out what it is. When your email client displays an inline image rather than downloading it, it doesn't analyze pixel patterns to recognize an image. When an API responds with JSON and your code parses it correctly, the parsing library doesn't guess the format.

In every case, the answer is the same: the Content-Type header told the software exactly what to expect.

Content types, formally called Internet Media Types (and colloquially known as MIME types), form the universal classification system that enables software worldwide to correctly interpret the data it receives. This system is elegantly simple yet powerful enough to classify every type of digital content humanity has ever created—and extensible enough to classify types that don't yet exist.

This page provides a complete exploration of content types: their structure, the seven discrete type families, the registration process, parameters, and the practical considerations every engineer must understand.

Every content type follows a precise syntactic structure defined in RFC 6838. Understanding this structure is essential for correctly parsing, generating, and working with media types.

The Fundamental Format

A media type consists of a type, a subtype, and optional parameters, structured as:

type "/" subtype *(";" parameter)

Where:

• type: The top-level category (e.g., text, image, application)
• subtype: The specific format within that category (e.g., plain, jpeg, json)
• parameters: Optional name=value pairs providing additional information

The type and subtype are case-insensitive by specification (though lowercase is conventional), while parameter values may be case-sensitive depending on the specific parameter.

The Subtype Naming Convention

Subtypes follow specific naming conventions that convey important information:

Standard subtypes are simple names registered with IANA:

• text/plain — Unformatted text
• image/jpeg — JPEG image format
• audio/mpeg — MPEG audio (e.g., MP3)

Vendor subtypes use the vnd. prefix for proprietary or vendor-specific formats:

• application/vnd.ms-powerpoint — Microsoft PowerPoint
• application/vnd.oasis.opendocument.text — OpenDocument text
• image/vnd.adobe.photoshop — Adobe Photoshop (PSD)

Personal/vanity subtypes use the prs. prefix (rarely used in practice):

• application/prs.example — Personal experimental format

Unregistered/experimental subtypes historically used the x- prefix:

• application/x-tar — Tar archive (now deprecated convention)
• application/x-www-form-urlencoded — HTML form data (grandfather exception)

Parameters and Their Syntax

Parameters extend media types with additional metadata. Each parameter is a name=value pair:

media-type = type "/" subtype *(";" parameter)
parameter = attribute "=" value
value = token / quoted-string

Key rules for parameter values:

1. Token values (unquoted) may contain only alphanumerics and a few special characters
2. Quoted-string values are enclosed in double quotes and may contain most characters
3. Special characters in values require quoting: space, comma, semicolon, equals, etc.
4. Double quotes within quoted strings are escaped with backslash: \")

Common parameters by type:

The text type encompasses all content that is human-readable without special processing. While computers may need encoding information to correctly render text, the content is fundamentally character data meant for human consumption.

Core Semantics

Content with text/* types:

• Consists of character sequences (not arbitrary bytes)
• Should be displayable to humans without transformation
• May use various character encodings (UTF-8, ISO-8859-1, etc.)
• Often has line-based structure with CRLF line endings in transport

The charset Parameter

For text types, the charset parameter is critically important. It specifies the character encoding used to convert between bytes and characters:

text/plain; charset=utf-8
text/html; charset=iso-8859-1
text/csv; charset=utf-16le

Without an explicit charset, the default depends on protocol:

• HTTP: ISO-8859-1 (per RFC 2616, though this is outdated practice)
• Email: US-ASCII
• Modern practice: Assume UTF-8, but always specify explicitly

Text vs Application: The Classification Dilemma

A persistent question is when to use text/* versus application/* for textual formats. The distinction is subtle:

• text/*: Content readable by humans in its encoded form
• application/*: Machine-processable content (even if it happens to be text)

Historically, this line was unclear. JavaScript was registered as application/javascript but widely served as text/javascript. XML exists as both text/xml and application/xml.

Modern best practice recommends:

• Use text/html for HTML
• Use text/css for CSS
• Use text/javascript for JavaScript (standardized in RFC 9239)
• Use application/json for JSON (despite being human-readable)
• Use application/xml for XML (for consistency with processing model)

The format=flowed Parameter

For text/plain, the format=flowed parameter (RFC 3676) provides soft-wrapping information:

text/plain; charset=utf-8; format=flowed

Flowed format indicates that soft line breaks may be recombined by recipients for display, while hard line breaks (no trailing space) must be preserved. This enables proper reformatting of plain text for different display widths.

These three type families cover rich media content — visual images, sound recordings, and moving pictures. While browsers and media players handle the heavy lifting of decoding and rendering, understanding these types is essential for web developers, API designers, and anyone working with multimedia content.

Image Types

The image type encompasses all visual graphical content. Modern web development requires familiarity with several distinct formats, each with different compression characteristics, browser support, and use cases.

Content Negotiation for Images

Modern web servers can serve different image formats based on browser capabilities:

GET /logo HTTP/1.1
Accept: image/avif, image/webp, image/png, image/jpeg, */*

The server can then respond with the optimal format the client supports. This technique enables serving smaller AVIF or WebP files to modern browsers while falling back to JPEG/PNG for older ones.

Audio Types

The audio type covers sound content, from simple notification sounds to complex musical compositions. Audio encoding is a deep technical field, but developers need to understand the practical aspects of format support and streaming.

Video Types

Video is the most complex media type, involving both visual frames and typically one or more audio tracks, subtitles, and metadata. Video formats often involve container formats (which hold multiple streams) and codecs (which encode/decode the streams).

The application type is the most diverse type family, serving as both a specific category and a catch-all for content that doesn't fit elsewhere. It encompasses machine-processable data, executable programs, compressed archives, office documents, and structured data formats.

Core Semantics

Content labeled application/* is:

• Intended for processing by applications rather than direct human reading
• May require specialized software to interpret
• Often binary, though textual formats (JSON, XML) are common
• The default when no other type fits

The Universal Fallback: application/octet-stream

When a sender doesn't know (or won't reveal) the content type, application/octet-stream serves as the generic binary type:

Content-Type: application/octet-stream
Content-Disposition: attachment; filename="mystery-file.bin"

Recipients typically offer to download such content rather than attempting to display or process it. Using octet-stream when you know the actual type is an anti-pattern—it prevents automatic handling.

Structured Data Formats

Modern APIs predominantly use two textual data formats:

JSON (application/json) has become the de facto standard for web APIs:

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

{"name": "Tanaka", "age": 28, "languages": ["Japanese", "English"]}

XML (application/xml) remains important for SOAP services, configuration, and enterprise systems:

Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>
<person><name>Tanaka</name><age>28</age></person>

Document Formats

Office productivity suites use vendor-prefixed MIME types:

The multipart type family is unique among MIME types—it's composite rather than discrete. While other types describe a single piece of content, multipart types contain multiple body parts, each with its own Content-Type.

The Boundary Mechanism

Multipart messages use a boundary string to delimit parts. This boundary:

• Must not appear in any of the enclosed content
• Is specified in the Content-Type header's boundary parameter
• Appears prefixed with -- to mark part boundaries
• Appears with -- suffix to mark the end of all parts

Content-Type: multipart/mixed; boundary="----=_Part_123"

------=_Part_123
Content-Type: text/plain

This is the first part.
------=_Part_123
Content-Type: image/png

[binary PNG data...]
------=_Part_123--

multipart/mixed — The General Container

The most common multipart type, used when parts are independent and meant to be processed sequentially. A typical email with attachments uses multipart/mixed:

Content-Type: multipart/mixed; boundary="MixedBoundary"

--MixedBoundary
Content-Type: text/plain

Please find the attached documents.

--MixedBoundary
Content-Type: application/pdf; name="report.pdf"
Content-Disposition: attachment; filename="report.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjcKJeLjz9MKN...

--MixedBoundary
Content-Type: image/png; name="chart.png"
Content-Disposition: attachment; filename="chart.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANS...

--MixedBoundary--

multipart/alternative — Format Selection

Used when the same semantic content is provided in multiple formats. Recipients choose the best format they can display. Parts are ordered from simplest to most feature-rich:

Content-Type: multipart/alternative; boundary="AltBoundary"

--AltBoundary
Content-Type: text/plain; charset=utf-8

Welcome to our newsletter!

--AltBoundary
Content-Type: text/html; charset=utf-8

<html><body><h1>Welcome to our newsletter!</h1></body></html>

--AltBoundary--

Email clients display the HTML version if supported, falling back to plain text if not.

multipart/form-data — Web Form Uploads

This type enables web forms to submit both text fields and binary files:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary="----FormBoundary"
Content-Length: 10234

------FormBoundary
Content-Disposition: form-data; name="username"

tanaka_yuki
------FormBoundary
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

[binary JPEG data...]
------FormBoundary
Content-Disposition: form-data; name="bio"

Software engineer from Tokyo.
------FormBoundary--

Each form field becomes a separate part, with file fields including the filename and Content-Type.

The message type family handles encapsulated messages—complete messages wrapped within other messages. This enables forwarding, digests, partial message delivery, and references to external content.

message/rfc822 — Complete Email Messages

When forwarding an email "as attachment" rather than inline, the original message is wrapped with:

Content-Type: message/rfc822
Content-Disposition: attachment; filename="Forwarded Message.eml"

From: original-sender@example.com
To: original-recipient@example.com
Subject: Original Subject
Date: Mon, 15 Jan 2024 10:30:00 +0900
MIME-Version: 1.0
Content-Type: text/plain

This was the original message body.

The entire original message, including all its headers and body, becomes the content of the message/rfc822 part. Recipients can save this part as a .eml file and open it in their email client.

message/partial — Large Message Splitting

Historically significant for bypassing message size limits, message/partial divides large messages into smaller fragments:

Content-Type: message/partial; id="unique-msg-id"; number=1; total=3

[First portion of the large message...]

Recipient systems reassemble the fragments using the id and number parameters. While rarely used today (modern systems handle large messages directly), understanding this mechanism provides insight into MIME's design for constrained environments.

message/external-body — Deferred Retrieval

This type tells recipients where to fetch content rather than including it directly:

Content-Type: message/external-body; access-type=URL;
    URL="https://example.com/large-attachment.zip"

Content-Type: application/zip
Content-Description: Large archive (150 MB)

The body contains headers describing what will be retrieved, while the actual content is fetched separately. This enables sending references to large files without transmitting them through email systems.

The Internet Assigned Numbers Authority (IANA) maintains the official registry of media types at iana.org/assignments/media-types. This centralized registry ensures global consistency and prevents conflicting type definitions.

Registration Process

New media types follow a structured registration process defined in RFC 6838:

1. Standards Tree Types (no prefix): Require IETF standards track publication

   • Example: application/json (RFC 8259)

2. Vendor Tree Types (vnd. prefix): Require registration application to IANA

   • Example: application/vnd.ms-excel

3. Personal/Vanity Tree (prs. prefix): Self-registered, no approval needed

   • Example: application/prs.my-custom-format

4. Unregistered Types (x- prefix): Deprecated but still widely used

   • Example: application/x-tar

What's in a Registration

A complete IANA media type registration includes:

• Type/subtype: The identifier itself
• Required parameters: Parameters that must be present
• Optional parameters: Parameters that may be present
• Encoding considerations: How content should be encoded for transport
• Security considerations: Potential security implications
• Interoperability considerations: Known compatibility issues
• Published specification: Reference to defining document
• Deprecated aliases: Old names for the same type
• Restrictions on usage: Any limitations on where the type applies

Discovering Unknown Types

When encountering an unknown media type:

1. Check IANA registry: The definitive source for official registrations
2. Examine the suffix: Types ending in +xml, +json, or +cbor indicate underlying format
3. Check vendor documentation: Types with vnd. prefix are documented by vendors
4. Fall back gracefully: Unknown types in known families (e.g., unknown image/*) can use generic handling

Content negotiation is the mechanism by which clients and servers agree on the best content representation to exchange. MIME types are central to this process, appearing in HTTP's Accept and Content-Type headers.

Client-Driven Negotiation (Accept Headers)

Clients express their preferences using the Accept header:

GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json, application/xml;q=0.9, text/html;q=0.5, */*;q=0.1

The quality factor (q) indicates preference strength (0.0 to 1.0):

• application/json — q=1.0 (default, highest priority)
• application/xml;q=0.9 — Second choice
• text/html;q=0.5 — Acceptable but not preferred
• */*;q=0.1 — Anything else as last resort

Servers select the highest-preference type they support and respond accordingly.

Server-Driven Negotiation

When servers have multiple representations available, they can indicate this with the Vary header:

HTTP/1.1 200 OK
Content-Type: application/json
Vary: Accept

{"name": "Example"}

The Vary: Accept header tells caches that responses differ based on the Accept header—caching infrastructure should store separate copies for different Accept values.

API Versioning with Content Types

Content types enable elegant API versioning:

# Client requests v2 API
Accept: application/vnd.example.v2+json

# Server responds with v2 format
Content-Type: application/vnd.example.v2+json

# Client that still needs v1
Accept: application/vnd.example.v1+json

This approach keeps version information in content type rather than URL paths, enabling cleaner API evolution.

Content types form the classification backbone of MIME and modern Internet protocols. Let's consolidate what we've learned:

What's Next

We've explored individual content types and how they classify content. The next page dives into multipart messages—how to construct and parse composite messages containing multiple parts, the boundary protocol, and nested structures that enable rich email content like HTML with inline images and multiple attachments.