Content-Type troubleshooting

multipart/form-data boundary errors

A multipart request declares its part delimiter in the Content-Type header: multipart/form-data; boundary=----BOUNDARY7. When the boundary parameter is malformed, servers and clients cannot find where one part ends and the next begins.

What a boundary is

The boundary parameter names the delimiter used in the body of a multipart message. Each part of the body is introduced by -- plus the boundary value, and the message ends with a final --boundary-- line. The header value and the body delimiters must use the same string.

• multipart/form-data is the media type for HTML form uploads; per RFC 7578 its Content-Type must include exactly one boundary parameter.
• multipart/mixed, multipart/alternative, and multipart/related are the other common members of the multipart family, with the same boundary mechanics (RFC 2046).

CorrectMIME validates the parameter syntax in the header value. Whether the header matches the delimiters actually present in the body is a separate check that only the message itself can confirm.

Common boundary parameter failures

Each example shows the broken form and the corrected form.

Missing value

Broken: multipart/form-data; boundary=

An empty boundary value leaves the delimiter unnamed. The header was likely truncated or assembled from a template whose boundary variable was empty.

Fixed: multipart/form-data; boundary=----BOUNDARY7

Missing equals sign

Broken: multipart/form-data; boundary ----BOUNDARY7

Without = the segment is a malformed parameter and the value is never attached to the name.

Fixed: multipart/form-data; boundary=----BOUNDARY7

Unterminated quoted value

Broken: multipart/form-data; boundary="----BOUNDARY7

A quoted boundary must close with a matching double quote. An unterminated quote can swallow the rest of the header.

Fixed: multipart/form-data; boundary="----BOUNDARY7"

Duplicate boundary parameters

Broken: multipart/form-data; boundary=----BOUNDARY7; boundary=----BOUNDARY8

Two boundary parameters are ambiguous: clients keep the first or the last, differently by implementation, and the body delimiters cannot match both. Emit exactly one boundary parameter.

Fixed: multipart/form-data; boundary=----BOUNDARY7

Unexpected characters

A boundary value is a token or a quoted string. Characters outside the token set, such as spaces, commas, or semicolons, must be inside double quotes:

• Quoted because of a space: multipart/form-data; boundary="simple boundary"
• Quoted because of a comma: multipart/form-data; boundary="a,b"
• Quoted because of a semicolon: multipart/form-data; boundary="part; one"

The common generated boundaries, such as ----WebKitFormBoundary7MA4YWxkTrZu0gW, contain only letters, digits, and hyphens, so they are safe as bare values without quotes.

Boundary limits and canonical form

RFC 2046 limits a boundary value to at most 70 characters. The validator does not enforce that limit; it reports syntax only. When a boundary is longer, the failure typically appears at the receiving application.

The canonical form removes whitespace around the separator and strips quotes when the value is safe without them. Values that still need quoting keep their quotes.

When the header is fine but the request still fails

If the header value validates but the receiver reports a missing boundary, the mismatch is between the header and the body: the delimiter lines in the body were generated from a different boundary string, or the boundary value exceeded the 70-character limit despite valid token syntax. These checks need the full message, and CorrectMIME's answer there is the same: the header side is well-formed, so inspect the generating code and the body delimiter lines.