Content-Type lookup
The HTTP Content-Type header carries a MIME (media) type that tells clients how to interpret a response body — render it, parse it, or download it. This tool is the reverse of an extension lookup: search by format name, file extension, or top-level type and get the exact type/subtype string, the extensions it covers, and the parameters (like charset) you should include.
Why getting Content-Type wrong causes real problems
A missing or incorrect Content-Type header is a surprisingly common source of bugs, security issues, and integration failures:
- Browsers sniff the content type when the header is absent or set to
application/octet-stream, which can cause HTML to be executed when only a download was intended — a classic cross-site scripting vector. - APIs fail to parse when a client sends JSON with
Content-Type: text/plainor omits the header entirely, even if the body is valid JSON. - File downloads break when the browser renders a file inline instead of triggering a save dialog, because
Content-Disposition: attachmentneeds to accompany an appropriate content type. - Caching goes wrong when proxies and CDNs see
application/octet-streamon a response that should be text and cache it differently than intended.
Setting the correct, specific content type is a small detail with outsized consequences.
How the lookup works
Each record pairs a canonical MIME type with its top-level type (text, image, audio, video, application, font), its matching file extensions, and any standard parameters. The search normalizes your query and matches against the type string, format name, and extensions, so json, .json, and application all surface the relevant entry. Text formats include the recommended charset=utf-8 parameter; binary formats omit it.
Common types and when to use each
Content-Type: text/html; charset=utf-8
For HTML responses. Always include charset=utf-8 to prevent browsers guessing the encoding.
Content-Type: application/json
For JSON API responses. The JSON spec mandates UTF-8, so charset is optional here.
Content-Type: application/x-www-form-urlencoded
For HTML form submissions (default encoding). Required for fetch() with form data sent as URL-encoded key=value pairs.
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary...
For file uploads. The boundary parameter is auto-generated by the browser when you use a form with enctype="multipart/form-data" or a FormData object.
Content-Type: image/svg+xml
SVG should use this type, not image/xml or text/xml, to render correctly and allow inline script execution in supporting contexts.
Content-Type: application/octet-stream
The generic binary fallback. Use when no specific type applies; pair with Content-Disposition: attachment; filename="file.ext" to force a download.
The charset parameter
Only text-based types need charset. Binary formats (images, audio, video, most application/* types) ignore it. The only text types where charset matters are:
text/html— always addcharset=utf-8text/plain— addcharset=utf-8for non-ASCII contenttext/css— modern browsers infer UTF-8, but explicit is cleanertext/csv— addcharset=utf-8when opening in Excel on Windows may be an issue
Tips
- For downloads, pair
application/octet-streamwith aContent-Disposition: attachmentheader to force a save dialog. application/jsonis defined as UTF-8 by spec, so addingcharsetis redundant though harmless.- Never serve user-uploaded HTML, SVG, or XML with
text/htmlif it came from an untrusted source — a type confusion attack could execute scripts in the victim’s browser.