MIME Types Reference
A media type identifies the format and processing semantics of a representation. Send the correct Content-Type, negotiate with Accept, and never trust upload metadata as proof of safe content.
Common API and form types
| Media type | Typical use |
|---|---|
| application/json | JSON API requests and responses. |
| application/problem+json | Problem Details error representations. |
| application/x-www-form-urlencoded | Simple HTML-style form fields encoded as key-value pairs. |
| multipart/form-data | Forms containing files or multiple body parts; requires a boundary parameter. |
| application/octet-stream | Generic binary data when no more specific type applies. |
| text/plain | Human-readable plain text. |
| application/xml | Generic XML application data. |
| text/csv | Comma-separated text, subject to an agreed dialect and encoding. |
For JSON, UTF-8 is the interoperable default and adding arbitrary charset values can create inconsistent handling. Vendor or domain-specific JSON types often use the +json structured suffix, but clients still need to understand the type's semantics rather than treating every JSON object as interchangeable.
Common web assets
| Media type | File examples |
|---|---|
| text/html | HTML documents. |
| text/css | Stylesheets. |
| text/javascript | JavaScript resources. |
| application/manifest+json | Web application manifests. |
| image/png | PNG raster images. |
| image/jpeg | JPEG images. |
| image/svg+xml | SVG vector images; active content requires careful handling. |
| image/webp | WebP images. |
| font/woff2 | WOFF2 web fonts. |
| application/pdf | PDF documents. |
| application/zip | ZIP archives. |
Content-Type versus Accept
Content-Type describes the representation in the current message. Accept lists response media ranges the client can process, optionally with preferences. If the server cannot consume the request media type, 415 Unsupported Media Type is appropriate. If it cannot produce an acceptable representation, 406 Not Acceptable may apply. An API should document defaults instead of guessing from a file extension.
Form upload boundaries
A multipart request includes a boundary parameter that separates its parts. Browsers and mature clients generate the boundary together with the encoded body. Manually setting Content-Type: multipart/form-data while letting the client build the body can omit the boundary and break parsing. Each file part can have its own content type and disposition metadata.
Secure file handling
Filename, extension, and declared media type are attacker-controlled. Enforce size limits before full processing, inspect file signatures where suitable, decode with hardened libraries, and store uploads outside executable locations. Generate server-side filenames, prevent path traversal, and serve untrusted content with a safe disposition and X-Content-Type-Options: nosniff. SVG, HTML, and PDF can carry active or complex content even when their type is correct.
Content encoding is separate
A media type describes the representation format. Content-Encoding describes transformations such as gzip applied to that representation. Base64 inside JSON is application-level data encoding, not an HTTP content encoding. Avoid labeling compressed bytes with the type of the uncompressed document unless the HTTP fields correctly describe both layers.
Frequently Asked Questions
What type should JSON APIs use?
Use application/json or a registered +json type with defined semantics.
Should multipart boundaries be manual?
Usually no. Let the HTTP client generate them.
Is extension enough for uploads?
No. Validate untrusted content according to policy.