The exact Content-Type header to send, including when to add charset=utf-8
Runs in your browser. Nothing you type is sent anywhere. Updated on 24 Oct 2026.The Content-Type header decides whether a browser renders your file, downloads it or refuses it. This page writes the header for you, and answers the part people get wrong: text/html and text/css need charset=utf-8, application/json does not because RFC 8259 fixes the encoding and defines no such parameter, and binary types never take one. Content-Disposition and nosniff can be added too.
Open the page with text/html already looked up and its header shown.
Type your own file's extension or type in the search box and select its row.
Leave the charset on "charset: as registered", or switch to "charset: always" or "charset: never".
Tick Force a download to add Content-Disposition, and Add nosniff for X-Content-Type-Options.
Press Copy header, or Ctrl+Enter, to copy the lines.
This MIME types lookup works in both directions. Give it an extension, a whole file name or a media type, and it returns the canonical type to send, the extensions that belong to it, the other spellings you will meet, the magic bytes at the start of the file, and whether the content is text or binary.
The part most lists skip is the charset. A type either defines a charset parameter, in which case leaving it out makes browsers guess and mangle anything outside ASCII, or it does not. text/html, text/css, text/csv and image/svg+xml want "; charset=utf-8". application/json does not: RFC 8259 fixes JSON as UTF-8 and registers no charset parameter at all. Binary types never take one. Each row says which case it is and why.
The formats this site already processes are read from its shared format table, so a signature added there appears here too. Everything else, from certificates to subtitles to installers, is listed in this tool's own table with the specification that registers it, or an honest note that nothing does. It all runs in your browser; nothing is looked up over the network.
The rest of the article, and all 6 questions about MIME Types, are on the MIME Types page.
application/json. Do not add a charset parameter: RFC 8259 section 11 defines JSON text as UTF-8 and registers no charset parameter for the type. Some servers still send text/json or application/x-json; both work in practice but neither is the registered spelling.
Add it to types that define the parameter and are read as characters: text/html, text/css, text/plain, text/csv, text/javascript and image/svg+xml. Leave it off types whose registration already fixes UTF-8, such as application/json, and off every binary type, where it means nothing.
Nothing, in practice. MIME type is the older name, from the email standard the idea came from. The registry IANA keeps is called the Media Types registry, and the HTTP specification says media type. The same string, text/html, is meant by both.
Usually the server sent application/octet-stream because its type map has no entry for the extension, or it sent Content-Disposition: attachment. Look up the right type here, add it to your server configuration, and drop the attachment header if you want the file shown in the page.
Still stuck? Ask about MIME Types and anybody who knows can answer. No account needed.
Same job, other tools: File to C Array – Turn any file into an unsigned char array for C or C++, like xxd -i · JSON to JSONL Converter – Turn a JSON array into JSON Lines, one record per line, for BigQuery or Elasticsearch · JSONL to JSON Converter – Turn JSON Lines or NDJSON into one JSON array, keeping big numbers exact · JSON Minifier – Strip whitespace from JSON for production · JSON Validator – Check JSON and see exactly where it breaks.
On the related tools: GraphQL Validator – Check a GraphQL query or schema for errors, optionally against your own SDL.
In the collection Debug and Inspect.