Content-Type troubleshooting

MIME and Content-Type parameter errors

Parameters follow the media type after semicolons: text/plain; charset=utf-8. They carry the details that receivers depend on, such as boundary for multipart messages, charset for text decoding, and profile parameters defined by particular media types. Each parameter needs a valid name and value; malformed quotes, missing values, and duplicates can stop a Content-Type value from being parsed reliably.

The parameter grammar

Every parameter has the same shape: a name, an equals sign, and a value.

text/plain; charset=utf-8

Multiple parameters are separated by semicolons:

text/csv; charset=utf-8; header=present

• A semicolon separates parameters. The RFC 2045 grammar expresses each parameter as name=value. CorrectMIME tolerates some surrounding whitespace found in real input and removes it from the canonical form.
• Names are case-insensitive. charset and CHARSET name the same parameter. CorrectMIME preserves value casing in its model; for the charset parameter specifically, UTF-8 and utf-8 are different serializations of the same case-insensitive charset name.
• A value is a token or a double-quoted string. Tokens use letters, digits, and a small set of symbols; anything else belongs inside double quotes.
• Values can be empty only as name="". A bare name= with nothing after the equals sign is incomplete.

Common parameter failures

These are the failures that appear in real headers, each with the broken form and the corrected form.

Missing value after "="

Broken: application/example; version=

A parameter that ends after the equals sign has no value. This often marks a truncated header or a template that produced an empty result.

Fixed: application/example; version=2

"=" missing between name and value

Broken: application/example; version 2

Without the equals sign the segment is a malformed parameter. The validator stops the parameter at the next semicolon or at the end of the value.

Fixed: application/example; version=2

Missing semicolon between parameters

Broken: text/csv; charset=utf-8 header=present

Without a separating semicolon, the boundary between the two parameters is lost. A receiver reads one parameter with a wide value, or splits it differently from what was intended. Media type parsers handle a value that contains a space in different ways, so behavior varies by client and library.

Fixed: text/csv; charset=utf-8; header=present

Unterminated quoted string

Broken: text/html; charset="utf-8

A quoted-string must open and close with a double quote. An unterminated quote can consume the rest of the header, including every parameter that follows.

Fixed: text/html; charset="utf-8" or text/html; charset=utf-8

Stray semicolons and empty segments

Broken: text/html;; charset=utf-8

A double semicolon leaves an empty segment where a parameter name should be. Strict checkers flag it and skip the segment; cleaning it up removes a source of receiver variance.

Fixed: text/html; charset=utf-8

Duplicate parameters

Broken: text/plain; charset=utf-8; charset=iso-8859-1

Duplicates are reported as an error, matched case-insensitively, so CHARSET=utf-8; charset=iso-8859-1 collides the same way. Receivers do not agree on which occurrence wins; some keep the first, others the last. Remove the extra declaration where the header is produced.

Fixed: text/plain; charset=utf-8

Illegal characters in a parameter name

Broken: text/plain; content type=text/plain

Parameter names use token syntax, so a space cannot be part of the name. CorrectMIME deliberately applies a conservative token set and also rejects some extension syntax that a specialized HTTP field specification may define. A rejection by this tool does not mean every such character is universally forbidden by MIME grammar.

Fixed: text/plain; content-type=text/plain

When a value must be quoted

A value that contains anything outside the token character set needs double quotes. The common cases are spaces, commas, semicolons, and quotes inside the value:

• application/example; profile="my profile"
• application/example; note="report, 2026-06-01"
• multipart/mixed; boundary="part; one"

Inside a quoted string, a literal quote or backslash is escaped with a backslash: \" and \\. Single quotes have no special meaning in this grammar. A value such as charset='utf-8' keeps the single quotes as part of the value; use double quotes if quoting is needed.

Parameters you will meet in the wild

Familiarity with the common parameters makes errors easier to spot when they appear in a log or a failing request:

• boundary on multipart/form-data and other multipart types, delimiting the parts of a form submission or message
• charset on text-based types, declaring the character encoding of the body
• version on some vendor types such as application/vnd.example+json documents
• header=present on text/csv payloads, signaling a header row
• level on legacy image types, selecting the compression level
• format on some streaming and font types, narrowing the payload profile

Parameters are application-defined by the media type. The syntax they share is the part that causes parsing failures; the meaning of each name comes from the type's specification.

In multipart/form-data, the field name and optional filename belong to each part's Content-Disposition header. They are not ordinary parameters of that part's Content-Type value.

How to fix a parameter error, step by step

1. Copy the complete header value and paste it into the Content-Type Validator.
2. Read the first reported issue: it is usually the one that broke parsing first.
3. Correct the parameter at the source: the serializer, form builder, CDN rule, or header constant that emitted it.
4. Re-validate, then re-run the failing request or client against the corrected header.
5. Track the corrected value into test fixtures so the same error does not ship twice.

Extended HTTP parameter syntax

Some HTTP header fields opt into extended parameter syntax such as filename*=UTF-8''caf%C3%A9.png. Here, filename* is normally a Content-Disposition parameter rather than a Content-Type parameter. The * and percent encoding are not universally forbidden by RFC 2045 token grammar; their meaning depends on the specification for the particular header field.

CorrectMIME validates a Content-Type value with a deliberately conservative parameter-token rule, so it may reject constructs supported by more specialized HTTP parameter extensions. It does not validate Content-Disposition semantics. In particular, multipart form-data uses name and filename on Content-Disposition; RFC 7578 says not to use filename* there.

What CorrectMIME checks

• Parameter name validity: token characters only, names cannot be quoted
• Presence of the = delimiter and of a value after it
• Semicolon separators, optional whitespace, and empty parameter segments
• Quoted-string balance and escaping
• Duplicate parameters, matched case-insensitively
• The media type structure the parameters attach to: type, subtype, and structured suffix
• Warnings for values longer than 512 characters

The tool validates the header value itself. It does not look up the IANA registry, examine message bytes, or parse a full HTTP request.

Canonical forms for common parameter inputs

The canonical form lowercases the type, subtype, and parameter names, normalizes whitespace around separators, removes quotes when the value is safe without them, and sorts parameters by name. Values are preserved exactly as written.

When a parameter list fails in one client and works in another, validate the value, correct the first reported problem at the source, and re-check before redeploying.