Content-Type Lookup

Find the right MIME content-type by format name, extension, or type tree.

Reverse-lookup MIME content-type strings by format name, file extension, or top-level type. See the canonical type/subtype, matching extensions, and common parameters like charset so you can set HTTP Content-Type headers correctly. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is a Content-Type header?

The HTTP Content-Type header tells the client what kind of data the response body contains, such as text/html; charset=utf-8. Browsers and APIs rely on it to parse, render, or download the payload correctly.

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/plain or 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: attachment needs to accompany an appropriate content type.
  • Caching goes wrong when proxies and CDNs see application/octet-stream on 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 add charset=utf-8
  • text/plain — add charset=utf-8 for non-ASCII content
  • text/css — modern browsers infer UTF-8, but explicit is cleaner
  • text/csv — add charset=utf-8 when opening in Excel on Windows may be an issue

Tips

  • For downloads, pair application/octet-stream with a Content-Disposition: attachment header to force a save dialog.
  • application/json is defined as UTF-8 by spec, so adding charset is redundant though harmless.
  • Never serve user-uploaded HTML, SVG, or XML with text/html if it came from an untrusted source — a type confusion attack could execute scripts in the victim’s browser.