Multipart form data (multipart/form-data) is an HTTP content type used for form submissions that include file uploads, encoding each field and file as a separate part in the request body.
By Vaibhav Jain · Last updated March 27, 2026
HTML forms can encode their data in three ways: application/x-www-form-urlencoded (the default), multipart/form-data, and text/plain. Multipart encoding is required when your form includes file inputs.
With the default URL encoding, form data is sent as key=value pairs joined by ampersands: name=Jane&email=jane@example.com. This works fine for text fields but can't handle binary file data.
Multipart encoding splits the request body into separate parts, each with its own content type. Text fields get their own part, and files get their own part with the original filename and MIME type preserved. A unique boundary string separates each part.
You enable multipart encoding by adding enctype="multipart/form-data" to your form tag: <form action="..." method="POST" enctype="multipart/form-data">. Without this attribute, file inputs are submitted as filename strings only — the actual file content is not sent.
FormsList processes multipart form submissions, extracting text field values from the multipart body. For file handling, FormsList captures text data; file uploads should be handled through a dedicated file storage service with the file URL submitted as a text field.
What is multipart form data? Multipart form data (formally multipart/form-data) is an HTTP content encoding type used for HTML form submissions that include file uploads alongside regular text fields. It is specified by setting the enctype attribute on the <form> element: <form enctype="multipart/form-data" method="POST" action="...">. When this encoding is used, the browser packages each form field and file as a separate "part" in the HTTP request body, with a randomly generated boundary string separating each part. This encoding is required for file uploads because the default form encoding (application/x-www-form-urlencoded) can only handle text key-value pairs and cannot transmit binary file content.
To understand multipart encoding, it helps to compare it with the default. With application/x-www-form-urlencoded (the default when no enctype is specified), the browser encodes all form fields as a single URL-encoded string: name=Jane+Doe&email=jane%40example.com&message=Hello+world. This format is compact and works well for text-only forms, but it has no mechanism for including binary data like images, PDFs, or other files. With multipart/form-data, the browser constructs a request body where each field is a separate "part" preceded by a boundary marker. Each part includes a Content-Disposition header with the field name (and filename for file uploads), an optional Content-Type header (e.g., image/png for an image file), and the field's value or file's binary content. The boundary string (e.g., ----WebKitFormBoundary7MA4YWxkTrZu0gW) is included in the request's Content-Type header so the server knows how to split the parts apart.
On the server side, parsing multipart form data requires specialized middleware or library support. In Node.js, libraries like multer, formidable, or busboy handle multipart parsing. In Python, frameworks like Django and Flask parse it natively. In PHP, multipart data is automatically parsed into $_POST (for text fields) and $_FILES (for uploaded files). The server reads each part, identifies whether it is a text field or a file, and makes the data available to application code. File parts are typically saved to temporary storage, then moved to permanent storage (a local filesystem, Amazon S3, Cloudflare R2, or similar) if the application logic accepts them.
FormsList accepts and correctly processes multipart/form-data submissions, extracting all text field values from the multipart body just as it does with URL-encoded submissions. For file attachments, FormsList is optimized as a text-data form backend — it captures all text fields but does not store uploaded binary files directly. The recommended pattern for forms that need file uploads alongside FormsList is to handle the file upload separately (using a client-side upload to a storage service like S3 or Cloudflare R2) and include the resulting file URL as a hidden text field in the form that is submitted to FormsList. A real-world example: a job application form collects the applicant's name, email, cover letter text, and a resume PDF. The frontend uploads the resume to an S3 presigned URL and stores the resulting file URL in a hidden input. When the form submits to FormsList with enctype="multipart/form-data", FormsList captures all text fields including the S3 file URL, stores the submission, and sends an email notification to the hiring manager with a clickable link to the resume.
<form enctype='multipart/form-data' method='POST'><input type='file' name='resume'></form>. The enctype attribute enables the browser to send the file's binary content.
A job application form with text fields (name, email) and a file field (resume PDF). Multipart encoding handles both types in a single submission.
A profile form with a photo upload field. The image binary data is encoded as a separate part in the multipart request body.
Set up your form backend in under a minute. No server required, no complex configuration — just a simple endpoint for your forms.