Why Does HTTP Still Use multipart/form-data for File Uploads?

Why multipart/form-data persists

Uploading files is a routine task for developers. The common implementation uses a FormData object on the front end and a server endpoint that expects multipart/form-data. Although frameworks hide the details, the underlying HTTP request follows a simple, well‑defined protocol that has been standardized since 1998.

Why application/x-www-form-urlencoded cannot carry files

The application/x-www-form-urlencoded format concatenates fields as key=value pairs separated by &. Binary data contains bytes that are not printable characters and many that clash with URL‑encoding rules. To embed binary data, each byte must be percent‑encoded ( %XX), expanding one byte to three characters and inflating the payload dramatically. Therefore, this format is designed for text fields, not large binary blobs.

RFC 2388 and the birth of multipart/form-data

RFC 2388 (1998) introduced multipart/form-data to solve the problem of sending multiple fields—including binary files—in a single HTTP request without converting the files to text. The protocol is independent of HTML forms; any HTTP client can use it.

Structure of a multipart request

A multipart request consists of several parts , each separated by a boundary string declared in the Content-Type header. Each part has its own headers (e.g., Content-Disposition and Content-Type) followed by a blank line and the raw data.

Example request (boundary abc123)

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=abc123
--abc123
Content-Disposition: form-data; name="file"; filename="a.png"
Content-Type: image/png

[binary data]
--abc123--

The boundary marks the start and end of each part, allowing the server to stream the request part by part without loading the entire body into memory.

Server‑side advantages

Compared with embedding files in JSON as Base64, multipart avoids two costs:

Size overhead: Base64 expands data by ~33%.

Memory usage: JSON parsers typically read the whole payload into memory before decoding.

Multipart enables streaming: the server can process each part as it arrives, writing files to disk immediately and keeping memory usage bounded to a single part.

Comparison of three approaches

urlencoded

Binary handling: each byte is escaped.

Size cost: 2–3× expansion.

Memory: full payload must be parsed.

JSON + Base64

Binary handling: encoded as text.

Size cost: ~33% expansion.

Memory: full payload buffered.

multipart/form-data

Binary handling: raw binary.

Size cost: negligible.

Memory: streamed per part.

Compression considerations

Multipart can compress the entire request (e.g., Content-Encoding: gzip) but cannot compress individual parts because only three headers are allowed per part, leaving no place to declare per‑part compression.

Why multipart survives after 30 years

A single HTTP request can carry both regular fields and files, with files transmitted in their original binary form.

The protocol’s simplicity, reliability, and ability to stream data make it hard to replace. New technologies like HTTP/2, gRPC, and JSON address other concerns (concurrency, service interfaces, data exchange) but do not solve the specific problem of a browser form submitting mixed text and binary data.

Conclusion

multipart/form-data remains the go‑to solution for file uploads because it efficiently packages multiple fields and binary files in one request without unnecessary encoding overhead, and its design continues to meet the needs of modern web applications.