Multipart Form Data MIME Type

What does multipart/form-data mean?

multipart/form-data represents an ordered set of named fields. Each field is a separate MIME part, so one request can carry short text values, binary files, and repeated field names without forcing every value into one text encoding. It is the standard HTML form encoding for file uploads and is also common in HTTP APIs.¹²

The media type has one required parameter: boundary. IANA assigns it no file extension and no magic number.¹ A complete HTTP header looks like this:

Content-Type: multipart/form-data; boundary=ExampleBoundary

The body uses that exact boundary to separate its parts:

--ExampleBoundary
Content-Disposition: form-data; name="title"

Field notes
--ExampleBoundary
Content-Disposition: form-data; name="attachment"; filename="notes.txt"
Content-Type: text/plain

Example file contents
--ExampleBoundary--

How multipart form data is structured

RFC 7578 builds on the general multipart MIME model. Each part must have Content-Disposition: form-data and a name parameter containing the original field name. A file part should also provide a filename when one is available. Parts may declare their own Content-Type; absent that header, the default is text/plain.²

The separators use CRLF line endings, two hyphens, and the boundary value. The final separator adds another two hyphens to mark the end of the body. The chosen boundary must not occur inside any part.²

Field order and duplicates matter. RFC 7578 says intermediaries must not reorder results or combine parts that share a field name. Multiple files selected for one form field are therefore sent as separate parts with the same name, rather than inside the older nested multipart/mixed structure.²

This is one reason a multipart payload is not safely represented as a simple object. These three parts are distinct and ordered:

name="tag"  value="history"
name="tag"  value="computing"
name="published"  value="yes"

A decoder should preserve them as an ordered list until the receiving application's schema decides how duplicate names should be interpreted.

Why the boundary causes parsing errors

The boundary in the header and the delimiter in the body must agree byte for byte. A common mistake is to construct a browser FormData object but manually set only this header:

Content-Type: multipart/form-data

That omits the boundary. When a browser serializes FormData, let it generate the Content-Type header so its automatically chosen boundary matches the body. The HTML Standard explicitly constructs the request media type by joining multipart/form-data; boundary= with the boundary produced by its encoding algorithm.³

Other common failures include:

• Using line endings or closing delimiters that do not follow multipart syntax.
• Decoding the whole request as text even though a part can contain arbitrary binary bytes.
• Splitting on a guessed boundary instead of parsing the declared parameter.
• Treating repeated field names as one value.
• Trusting a submitted filename as a safe local path.

Use a maintained multipart parser for the server framework rather than splitting the body manually.

History and standardization

Ernesto Nebel and Larry Masinter introduced multipart/form-data in RFC 1867 in November 1995. Their proposal added file upload controls to HTML and defined a multipart representation that could efficiently transfer binary files alongside other form values.⁴

RFC 2388 later documented the format in 1998. The current Standards Track specification is RFC 7578, published in July 2015, which obsoleted RFC 2388 and updated the IANA registration.²

The newer specification reflects deployed web practice. Among other changes, it requires multiple files for one field to use repeated parts, deprecates Content-Transfer-Encoding for binary-capable transports such as HTTP, and advises implementations on non-ASCII names and values.²

Browser and application support

Current Chrome, Edge, Firefox, Opera, and Safari support multipart HTML form submission and the JavaScript FormData interface. MDN classifies FormData as widely available across browsers. It can be sent with fetch(), XMLHttpRequest.send(), or navigator.sendBeacon() using the same representation as a form with enctype="multipart/form-data".⁵

An HTML file-upload form uses POST and declares the encoding explicitly:

<form method="post" enctype="multipart/form-data">
  <input name="caption">
  <input type="file" name="attachment">
  <button>Upload</button>
</form>

curl creates multipart requests with --form or -F. Prefixing a value with @ attaches the named file as a file upload.⁶

curl --form 'caption=Field notes' \
  --form '[email protected];type=text/plain' \
  https://example.com/upload

Support in Poly

Poly recognizes the multipart/form-data MIME identifier and preserves labeled payloads for storage, sync, sharing, versioning, and download. It does not unpack the multipart body, extract individual fields or attachments, or provide a specialized preview.

You can find the stored payload by filename and ordinary file properties. Text field values, submitted filenames, and embedded file contents are not searchable, and the Poly agent cannot read them from the multipart container.

For useful content search, parse the request with a trusted tool and save the fields or attachments as appropriately typed files. Keep the original payload when exact request evidence matters.

multipart/form-data compared with URL encoding and JSON

Choose the representation that fits the data model rather than using multipart for every request.

Multipart field values do not gain JSON types. A part containing true or 42 is still text or bytes until an application schema interprets it. Likewise, a filename parameter describes a submitted name, not proof of the part's format or safety.

How to inspect or convert a multipart payload

A valid conversion needs both the body and its full Content-Type, including the boundary. Parse the body into an ordered collection of parts, then handle each part according to its declared type and the receiving application's contract.

A practical inspection workflow is:

1. Preserve the original body and Content-Type header.
2. Set limits for total bytes, part count, header size, and individual file size.
3. Parse with a maintained MIME or web-framework multipart library.
4. Retain duplicate names and original order.
5. Save file parts under newly generated safe names and validate their actual formats.
6. Export text fields to JSON only after deciding how duplicates and character encodings should map.

There is no lossless universal conversion to JSON because JSON has no byte-string type, per-part headers, or repeated object keys with guaranteed order. A conversion can use arrays for duplicate fields and Base64 for file bytes, but that is an application convention rather than the meaning of multipart/form-data.

Security and privacy considerations

Multipart encoding provides no confidentiality, integrity, authentication, or validation. RFC 7578 notes that form data often contains confidential or personally identifying information. Protect HTTP submissions with HTTPS and apply authorization, request-size limits, and cross-site request controls at the application layer.²

Multipart parsers should also bound memory, disk use, header length, part count, nesting, and processing time. Stream large uploads when possible. Reject malformed or incomplete bodies instead of guessing where one part ends and another begins.

Does multipart/form-data have a file extension?

No. IANA lists no extension or magic number for multipart/form-data.¹ It normally appears as a protocol message body whose framing depends on a boundary declared in the accompanying header.

Files named .multipart or .form-data may be useful local conventions, but they are not registered extensions. A filename alone also cannot preserve the required boundary parameter. If you archive a raw payload, save its HTTP metadata alongside it.