Content Types: MIME Types and Media Types

When your browser receives data from a server, how does it know whether to render HTML, display an image, play a video, or trigger a file download? The answer lies in Content Types—formally known as MIME Types (Multipurpose Internet Mail Extensions) or Media Types.

Every HTTP response includes a Content-Type header that declares the format of the body:

Content-Type: text/html; charset=utf-8
Content-Type: application/json
Content-Type: image/png
Content-Type: application/pdf

This seemingly simple mechanism enables the entire richness of the web—documents, APIs, streaming media, file downloads, and interactive applications—all transmitted over the same HTTP protocol with the recipient knowing exactly how to interpret each payload.

MIME types follow a hierarchical structure defined by RFC 2045 and maintained by IANA (Internet Assigned Numbers Authority).

Basic Structure

type/subtype; parameter=value

Examples:

text/html
application/json; charset=utf-8
image/png
multipart/form-data; boundary=----WebKitFormBoundary

Components Explained

Type (Top-Level): The general category of data

• text — Human-readable text
• image — Visual bitmap or vector data
• audio — Sound data
• video — Moving images
• application — Binary data or application-specific formats
• multipart — Multiple body parts
• font — Font data (added later)
• model — 3D model data

Subtype: Specific format within the type

• text/plain, text/html, text/css
• image/png, image/jpeg, image/svg+xml
• application/json, application/pdf, application/xml

Parameters: Additional format details

• charset=utf-8 — Character encoding
• boundary=abc123 — Multipart delimiter
• profile=high — Codec profile

Vendor and Personal Types

Beyond standard types, MIME allows custom types:

Vendor Types (vnd.): Registered by companies

application/vnd.ms-excel
application/vnd.google-apps.document
application/vnd.api+json

Personal/Experimental Types (prs./x-): Unregistered

application/x-www-form-urlencoded
application/prs.custom-format

Note: The x- prefix is deprecated for new types but remains in widespread use (e.g., text/x-python).

Suffix Conventions

Suffixes indicate underlying format structure:

This allows generic XML/JSON parsers to process data even without knowing the specific format.

Text types represent human-readable content. Character encoding is crucial for these types.

Character Encoding (Charset)

For text types, charset is critical:

Content-Type: text/html; charset=utf-8
Content-Type: text/plain; charset=iso-8859-1

Why charset matters:

• Without charset, browsers may guess (often wrongly)
• Wrong charset → garbled characters (mojibake: ç becomes ç)
• Security implications (charset sniffing attacks)

Best practice: Always specify charset=utf-8 for text content. UTF-8 is the universal standard that supports all languages.

HTML Charset Declaration

For HTML, you should also declare charset in the document:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <!-- Or equivalently: -->
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>

The HTTP header takes precedence, but including both ensures correct handling in all scenarios (cached copies, local files, etc.).

JavaScript Content Type Evolution

# Historical (still valid)
application/javascript
application/x-javascript
text/javascript

# Modern standard (RFC 9239, 2022)
text/javascript

RFC 9239 officially obsoleted application/javascript in favor of text/javascript. All browsers accept both, but use text/javascript for new projects.

application/* types represent data that requires specific processing—from structured data formats to binary executables.

application/json — The API Standard

Content-Type: application/json

JSON (JavaScript Object Notation) is the dominant format for web APIs:

Characteristics:

• UTF-8 encoding assumed (charset parameter optional)
• Human-readable yet compact
• Native JavaScript compatibility
• Supported by virtually every programming language

Variants and Extensions:

application/octet-stream — The Binary Fallback

When the server doesn't know (or won't tell) the specific format:

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

Browsers typically trigger a download dialog for this type. It's the safe default for unknown binary content.

application/x-www-form-urlencoded

The default format for HTML form submissions:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=john%40example.com&password=s%26cret!

Encoding rules:

• Spaces become + or %20
• Special characters URL-encoded (@ → %40, & → %26)
• Key-value pairs joined by &

Limitation: Cannot handle binary data efficiently; use multipart/form-data for file uploads.

Media types are crucial for web performance and compatibility. Choosing the right format affects loading speed, quality, and browser support.

Image Format Selection

Photo? → JPEG (or WebP for modern browsers)
Graphic/Screenshot? → PNG (or WebP)
Need transparency? → PNG, WebP, or AVIF
Vector/Scalable? → SVG
Animation? → GIF (simple) or WebP/AVIF (modern)
Best compression? → AVIF > WebP > JPEG/PNG

Modern Image Delivery with Picture Element

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Fallback for older browsers">
</picture>

Servers can also use content negotiation with the Accept header:

# Client request
GET /image HTTP/1.1
Accept: image/avif, image/webp, image/jpeg

# Server response (best format for client)
HTTP/1.1 200 OK
Content-Type: image/avif
Vary: Accept

Video Streaming Considerations

For adaptive streaming, content types vary:

# HLS (HTTP Live Streaming)
Content-Type: application/vnd.apple.mpegurl  # .m3u8 playlist
Content-Type: video/mp2t  # .ts segments

# DASH (Dynamic Adaptive Streaming)
Content-Type: application/dash+xml  # .mpd manifest
Content-Type: video/mp4  # .m4s segments

Partial Content for Media Seeking

Media players request specific byte ranges:

GET /video.mp4 HTTP/1.1
Range: bytes=1000000-1999999

HTTP/1.1 206 Partial Content
Content-Type: video/mp4
Content-Range: bytes 1000000-1999999/50000000

This enables seeking without downloading the entire file.

Multipart types allow a single HTTP message to contain multiple, distinct parts—essential for file uploads and complex data.

multipart/form-data Structure

This is the standard for file uploads from browsers:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="title"

My Document
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="report.pdf"
Content-Type: application/pdf

(binary PDF content)
------WebKitFormBoundary7MA4YWxkTrZu0gW--

Anatomy of Multipart Messages

1. Boundary: Unique string that separates parts

   • Defined in Content-Type header
   • Must not appear in the content
   • Prefixed with -- when used

2. Part Headers: Each part has its own headers

   • Content-Disposition: Field name and filename
   • Content-Type: MIME type of this part

3. Terminator: Final boundary with trailing --

When to Use multipart/form-data vs. JSON

Use multipart/form-data:

• File uploads (required)
• Mixed content (files + metadata together)
• Binary data

Use application/json:

• Pure data APIs (no files)
• When you need complex nested structures
• When clients prefer JSON

Hybrid approaches:

1. Separate requests: POST JSON metadata, then POST file separately
2. Base64 in JSON: Encode files as base64 (inefficient but sometimes convenient)
3. Multipart with JSON part: Include JSON as one part of multipart

Content negotiation allows clients and servers to agree on the best representation of a resource. The client expresses preferences; the server selects the best match.

Accept Header for Content Type Negotiation

GET /api/user/123 HTTP/1.1
Accept: application/json, application/xml;q=0.9, */*;q=0.1

Parsing:

• application/json — Quality 1.0 (default if not specified)
• application/xml;q=0.9 — Quality 0.9 (slightly less preferred)
• */*;q=0.1 — Any other type at 0.1 (fallback)

Server Response Based on Accept

# If server supports JSON (preferred)
HTTP/1.1 200 OK
Content-Type: application/json
Vary: Accept

{"id": 123, "name": "John"}

# If server only supports XML
HTTP/1.1 200 OK 
Content-Type: application/xml
Vary: Accept

<user><id>123</id><name>John</name></user>

# If no match possible
HTTP/1.1 406 Not Acceptable
Content-Type: application/json

{"error": "Cannot produce a response matching Accept header"}

Language Negotiation

GET /page HTTP/1.1
Accept-Language: es, en-US;q=0.9, en;q=0.8

Server priority:

1. Spanish (es) — q=1.0 (default)
2. American English (en-US) — q=0.9
3. Any English (en) — q=0.8

HTTP/1.1 200 OK
Content-Language: es
Vary: Accept-Language

<html lang="es">...</html>

Encoding Negotiation

GET /script.js HTTP/1.1
Accept-Encoding: gzip, deflate, br

Server returns:

HTTP/1.1 200 OK
Content-Encoding: br
Vary: Accept-Encoding

(brotli-compressed content)

The Vary Header

Critically important for caching:

Vary: Accept, Accept-Encoding, Accept-Language

What Vary tells caches: "This response varies based on these request headers. Cache separate versions for different Accept values."

Without Vary: A cache might serve a JSON response to a client that requested XML, or vice versa.

The Content-Disposition header controls how browsers handle responses—particularly whether to display inline or trigger a download.

Handling Filename Encoding

Filenames with non-ASCII characters or special characters require careful encoding:

# ASCII filename (simple)
Content-Disposition: attachment; filename="report.pdf"

# Non-ASCII filename (RFC 5987)
Content-Disposition: attachment; filename="report.pdf"; filename*=UTF-8''%E5%A0%B1%E5%91%8A.pdf

# Filename with quotes (escape with backslash)
Content-Disposition: attachment; filename="John's \"Special\" Report.pdf"

Browser compatibility:

• Modern browsers: Use filename* with UTF-8 encoding
• Include both filename and filename* for compatibility
• The filename* takes precedence when both are present

Security Considerations

Path traversal prevention:

# Dangerous - might attempt path traversal
Content-Disposition: attachment; filename="../../../etc/passwd"

# Server should validate:
- Strip path components
- Sanitize to basename only
- Whitelist allowed characters

Content-Type matters for inline:

# Safe - browser knows how to display
Content-Type: image/png
Content-Disposition: inline

# Dangerous - might execute
Content-Type: text/html
Content-Disposition: inline
# User-uploaded HTML could contain XSS!

Best practice for user uploads:

1. Validate Content-Type on upload
2. Store with controlled filenames (not user-provided)
3. Serve with attachment by default
4. Add Content-Security-Policy headers