Trexmi
Developer Ready

Content-Type Parser

Split a Content-Type header into media type, subtype, charset, boundary and other parameters. Accepts the full header line or just the value.

Accepts the full header line or only the value Separates type, subtype, charset and boundary Lists every parameter Rejects values that are not a valid media type
INPUT Content-Type header *
0 chars0 words0 lines
Ctrl / ⌘ + Enter
Content-Type details
About the tool

What Content-Type Parser does

The Content-Type parser breaks an HTTP Content-Type header into its parts: the media type (for example application/json), the top-level type and subtype, the charset, the multipart boundary and any other parameters. Paste either the whole line, such as Content-Type: text/html; charset=UTF-8, or only the value.

It is handy when an API client rejects a response, a file upload fails on the server, or a multipart body will not parse and you need to see exactly what the header says. To inspect a full set of response headers, use the HTTP Header Checker.

content-type parser splitting a header into media type, charset and boundary
A Content-Type header split into its fields.

How to use

  1. Paste the header. With or without the leading Content-Type:.
  2. Run the parser. The value is split at each semicolon.
  3. Read the fields. Media type, type, subtype, charset and boundary are shown first, then every parameter.
  4. Compare with what your code expects. A wrong charset or a missing boundary is a common cause of parse errors.
Built for the task

Why use Content-Type Parser?

Focused controls, predictable output, and a workflow designed around this exact transformation.

01

Header or value

The leading header name is stripped automatically.

02

Boundary and charset up front

The two parameters you usually look for are shown first, even when absent.

03

Strict media type check

Input that is not a valid type/subtype pair is rejected instead of guessed.

04

All parameters listed

Extra parameters such as version or profile are shown as key and value.

Useful answers

Questions about Content-Type Parser

Practical details about input, output, privacy, limits, and the best way to use this tool.

01 What does the Content-Type header contain?

It names the media type of a message body, such as text/html or application/json, followed by optional parameters separated by semicolons, such as charset=utf-8 or boundary=....

02 Do I need to include “Content-Type:” in the input?

No. The tool accepts both the full header line and the bare value.

03 What is the boundary used for?

In multipart/* bodies, such as file uploads, the boundary is the string that separates the parts. The receiving side needs it to split the body, so it must match the one used in the body exactly.

04 Why does the parser say “Enter a valid Content-Type value”?

The first part of the input is not a valid type/subtype pair. Check for a missing slash, spaces inside the type, or a stray character in front of it.

05 Is the charset checked against a list of encodings?

No. The charset is reported as written. Verify that the name is one your server or client actually supports.

06 Are quoted values with semicolons handled?

Not fully. The value is split at every semicolon, so a quoted parameter that itself contains a semicolon would be cut in two. This is rare in practice, but check such headers by hand.

07 Does it detect the real file type of a file?

No. It parses only the header text you give it. The declared type can differ from the actual content of a file.

How a Content-Type header is built

The header starts with a media type made of a top-level type and a subtype, separated by a slash. After it come optional parameters written as name=value and separated by semicolons. Common top-level types are text, application, image, audio, video, multipart and font. Media types and parameter names are case-insensitive.

Parameters you will meet most often

  • charset tells the receiver which text encoding to use, for example utf-8. It is typical for text/* and for JSON served with an explicit charset.
  • boundary separates the parts in multipart/form-data and multipart/mixed bodies.
  • version, profile and similar parameters are used by some API formats to select a variant.

Typical problems this tool helps find

  • A form upload sent as multipart/form-data without a boundary, so the server cannot split the body.
  • A client that sets the content type by hand and overrides the boundary generated for the body.
  • JSON sent as text/plain or application/x-www-form-urlencoded, so the server does not parse it.
  • A wrong or missing charset that shows up as garbled non-ASCII characters.

Limits to keep in mind

The tool parses the text you paste. It does not fetch URLs, does not check that the body matches the declared type and does not validate charset names. A header can be syntactically valid and still be wrong for your endpoint, so confirm the expected value in the API documentation.

Related tools

Check a whole response with the HTTP Header Checker, compose headers with the HTTP Header Builder, or decode a data: URL, which also carries a media type, with the Data URL Decoder.

External reference

The header is defined in RFC 9110, section 8.3, and multipart bodies in RFC 2046, section 5.1.