2010-12-24 12:19:27 8 Comments

What does enctype='multipart/form-data' mean in an HTML form and when should we use it?


@Quentin 2010-12-24 12:21:56

When you make a POST request, you have to encode the data that forms the body of the request in some way.

HTML forms provide three methods of encoding.

  • application/x-www-form-urlencoded (the default)
  • multipart/form-data
  • text/plain

Work was being done on adding application/json, but that has been abandoned.

(Other encodings are possible with HTTP requests generated using other means than an HTML form submission.)

The specifics of the formats don't matter to most developers. The important points are:

  • Never use text/plain.

When you are writing client-side code:

  • use multipart/form-data when your form includes any <input type="file"> elements
  • otherwise you can use multipart/form-data or application/x-www-form-urlencoded but application/x-www-form-urlencoded will be more efficient

When you are writing server-side code:

  • Use a prewritten form handling library

Most (such as Perl's CGI->param or the one exposed by PHP's $_POST superglobal) will take care of the differences for you. Don't bother trying to parse the raw input received by the server.

Sometimes you will find a library which can't handle both formats. Node.js's most popular library for handling form data is body-parser which cannot handle multipart requests (but has documentation which recommends some alternatives which can).

If you are writing (or debugging) a library for parsing or generating the raw data, then you need to start worrying about the format. You might also want to know about it for interest's sake.

application/x-www-form-urlencoded is more or less the same as a query string on the end of the URL.

multipart/form-data is significantly more complicated but it allows entire files to be included in the data. An example of the result can be found in the HTML 4 specification.

text/plain is introduced by HTML 5 and is useful only for debugging — from the spec: They are not reliably interpretable by computer — and I'd argue that the others combined with tools (like the Net tab in the developer tools of most browsers) are better for that).

@Webinan 2013-10-20 09:47:39

@Quentin Excuse me, what will be any probable problem if we use multipart for all forms? with and whit out files.

@Quentin 2013-10-20 10:46:50

It doesn't make sense for GET forms, and it makes the file size of requests bigger.

@Devrath 2013-11-22 09:05:03

@ Quentin ..... [+1] FOR GREAT ANSWER .... can you point a web source .... that shows the structure of multipart/form-data ..... espically when a string with an image is involved ..... Thanks !

@Growler 2017-02-13 23:06:00

@Quentin does multipart form data send as a stream by default?

@Philip Rego 2017-12-10 21:54:59

Does the enc in enctype stand for something?

@Quentin 2017-12-10 22:15:12

"HTML forms provide three methods of ENCoding"

@Quentin 2019-01-10 15:38:55

@Damon — The content-type on the request needs to be set correctly, and standard best practice would mean you would set up the form correctly (it just won't do anything except when the JS fails).

@Seagull 2019-02-15 13:30:17

For sending files multipart is key!

@Qwerty 2019-02-27 18:05:14

Why is application/json discontinued, yet it still works and can be found in documentations of various services such as bitbucket, etc?

@Quentin 2019-02-27 18:06:27

@Qwerty — It never worked. Browsers have never done anything if you set the enctype of a form to that value. (What web services accept from sources other than form submissions is not relevant).

@Qwerty 2019-02-27 18:16:26

I can certainly send a JSON in my request payload and I see a content-type: application/json;charset=UTF-8 in both, Request Headers and Response Headers, when viewing the request detail in Networks tab in Chrome. How come then? I am confused. Thanks for your super-fast reply btw.

@Quentin 2019-02-27 18:17:20

@Qwerty — "I can certainly send a JSON in my request payload" — You cannot do that by using the enctype attribute of a form.

@Qwerty 2019-02-27 18:22:45

Oh I see!, that's the root of my confusion. See, I am not sending a form. That's a fetch request with {method: 'POST', headers: { 'content-type': 'application/json' }}. So it is valid after all, but not supported natively by forms, right?

@Quentin 2019-02-27 18:23:43

Yes. This question is entirely about HTML forms and not other sources of request (such as fetch, xmlhttprequest, postman, LWP, and cURL).

@Qwerty 2019-02-27 18:27:39

Oh, right, I was looking for how to implement multipart/form-data with fetch, ended up here, didn't notice that. Blame google. Thanks anyway.

@Ciro Santilli 新疆改造中心996ICU六四事件 2015-02-07 09:52:03

when should we use it

Quentin's answer is right: use multipart/form-data if the form contains a file upload, and application/x-www-form-urlencoded otherwise, which is the default if you omit enctype.

I'm going to:

  • add some more HTML5 references
  • explain why he is right with a form submit example

HTML5 references

There are three possibilities for enctype:

How to generate the examples

Once you see an example of each method, it becomes obvious how they work, and when you should use each one.

You can produce examples using:

Save the form to a minimal .html file:

<!DOCTYPE html>
<html lang="en">
  <meta charset="utf-8"/>
<form action="http://localhost:8000" method="post" enctype="multipart/form-data">
  <p><input type="text" name="text1" value="text default">
  <p><input type="text" name="text2" value="a&#x03C9;b">
  <p><input type="file" name="file1">
  <p><input type="file" name="file2">
  <p><input type="file" name="file3">
  <p><button type="submit">Submit</button>

We set the default text value to a&#x03C9;b, which means aωb because ω is U+03C9, which are the bytes 61 CF 89 62 in UTF-8.

Create files to upload:

echo 'Content of a.txt.' > a.txt

echo '<!DOCTYPE html><title>Content of a.html.</title>' > a.html

# Binary file containing 4 bytes: 'a', 1, 2 and 'b'.
printf 'a\xCF\x89b' > binary

Run our little echo server:

while true; do printf '' | nc -l 8000 localhost; done

Open the HTML on your browser, select the files and click on submit and check the terminal.

nc prints the request received.

Tested on: Ubuntu 14.04.3, nc BSD 1.105, Firefox 40.


Firefox sent:

[[ Less interesting headers ... ]]
Content-Type: multipart/form-data; boundary=---------------------------735323031399963166993862150
Content-Length: 834

Content-Disposition: form-data; name="text1"

text default
Content-Disposition: form-data; name="text2"

Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain

Content of a.txt.

Content-Disposition: form-data; name="file2"; filename="a.html"
Content-Type: text/html

<!DOCTYPE html><title>Content of a.html.</title>

Content-Disposition: form-data; name="file3"; filename="binary"
Content-Type: application/octet-stream


For the binary file and text field, the bytes 61 CF 89 62 (aωb in UTF-8) are sent literally. You could verify that with nc -l localhost 8000 | hd, which says that the bytes:

61 CF 89 62

were sent (61 == 'a' and 62 == 'b').

Therefore it is clear that:

  • Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266 sets the content type to multipart/form-data and says that the fields are separated by the given boundary string.

  • every field gets some sub headers before its data: Content-Disposition: form-data;, the field name, the filename, followed by the data.

    The server reads the data until the next boundary string. The browser must choose a boundary that will not appear in any of the fields, so this is why the boundary may vary between requests.

    Because we have the unique boundary, no encoding of the data is necessary: binary data is sent as is.

    TODO: what is the optimal boundary size (log(N) I bet), and name / running time of the algorithm that finds it? Asked at:

  • Content-Type is automatically determined by the browser.

    How it is determined exactly was asked at: How is mime type of an uploaded file determined by browser?


Now change the enctype to application/x-www-form-urlencoded, reload the browser, and resubmit.

Firefox sent:

[[ Less interesting headers ... ]]
Content-Type: application/x-www-form-urlencoded
Content-Length: 51


Clearly the file data was not sent, only the basenames. So this cannot be used for files.

As for the text field, we see that usual printable characters like a and b were sent in one byte, while non-printable ones like 0xCF and 0x89 took up 3 bytes each: %CF%89!


File uploads often contain lots of non-printable characters (e.g. images), while text forms almost never do.

From the examples we have seen that:

  • multipart/form-data: adds a few bytes of boundary overhead to the message, and must spend some time calculating it, but sends each byte in one byte.

  • application/x-www-form-urlencoded: has a single byte boundary per field (&), but adds a linear overhead factor of 3x for every non-printable character.

Therefore, even if we could send files with application/x-www-form-urlencoded, we wouldn't want to, because it is so inefficient.

But for printable characters found in text fields, it does not matter and generates less overhead, so we just use it.

@Khanna111 2015-08-06 18:42:10

Great post. Question: Why do we have 3 bytes for each non printable character? For eg: for unicode U+03C9, we have %CF%89: this is 2 extra bytes for the two "%". Is my understanding correct?

@Ciro Santilli 新疆改造中心996ICU六四事件 2015-08-06 18:50:17

@Khanna111%CF is 3 bytes long: %, C and F :-) Story of making it human readable.

@starfry 2015-08-27 18:36:01

I had to use a slightly different listener: while true; do printf '' | nc -lp 8000; done

@Ciro Santilli 新疆改造中心996ICU六四事件 2015-08-28 08:05:49

@starfry what error did you get on the command I've given? What is your nc version and distro? I'm netcat-openbsd 1.105-7ubuntu1 Ubuntu 14.04.3.

@starfry 2015-08-28 14:52:34

I have gnu-netcat 0.7.1-5 on Arch Linux. It's doc states that -l is needed for listen mode and -p to specify the port. The optional host and port arguments restrict connections to a specific remote host and port. There is no error because the command as written in the answer opens a connection that listens on a random port for connections from localhost:8000.

@Ciro Santilli 新疆改造中心996ICU六四事件 2015-08-28 15:41:04

@starfry can you check that: while true; do printf '' | nc -lp 8000 localhost; done works for you? It seems to work on both version, if it does I'll update to use that instead, otherwise I'll just mention both commands.

@starfry 2015-08-28 15:44:59

Yes, while true; do printf '' | nc -lp 8000 localhost; done works fine.

@Ramazan Polat 2016-11-06 05:41:20

This should be the actual answer.

@Saar 2017-03-26 03:14:21

+1, very comprehensive. You may want to align the boundary string under "Therefore it is clear that:" with the one in the request

@PhilipS 2017-04-25 02:03:03

On OS X, nc won't accept both the -l and the -p arguments simultaneously. But this works for me: while true; do printf '' | nc -l 8000; done.

@Ciro Santilli 新疆改造中心996ICU六四事件 2017-04-25 05:37:52

@PhilipS actually, -p is unecessary on Linux as well and I've removed it. Thanks for bringing that up.

@Bernard 2017-07-03 12:34:29

A small but important point that isn't mentioned is that the boundary specified in the Content-Type has two hyphens (--) less, i.e. when actually using the boundary in the message body, you must prefix it with --. Also, the last boundary must be suffixed with --, but that is easy enough to notice. See…

@Siva Prakash 2019-02-13 07:54:56

Such a detailed and deep answer.Thanks a lot.

@Andry 2010-12-24 17:50:10

When submitting a form, you tell your browser to send, via the HTTP protocol, a message on the network, properly enveloped in a TCP/IP protocol message structure. An HTML page has a way to send data to the server: by using <form>s.

When a form is submitted, an HTTP Request if created and sent to the server, the message will contain the field names in the form and the values filled in by the user. This transmission can happen with POST or GET HTTP methods.

  • POST tells your browser to build an HTTP message and put all content in the body of the message (a very useful way of doing things, more safe and also flexible).
  • GET will submit the form data in the querystring. It has some constraints about data representation and length.

Stating how to send your form to the server

Attribute enctype has sense only when using POST method. When specified, it instructs the browser to send the form by encoding its content in a specific way. From MDN - Form enctype:

When the value of the method attribute is post, enctype is the MIME type of content that is used to submit the form to the server.

  • application/x-www-form-urlencoded: This is the default. When the form is sent, all names and values are collected and URL Encoding is performed on the final string.
  • multipart/form-data: Characters are NOT encoded. This is important when the form has a file upload control. You want to send the file binary and this ensures that bitstream is not altered.
  • text/plain: Spaces get converted, but no more encoding is performed.


When submitting forms, some security concerns can arise as stated in RFC 7578 Section 7: Multipart form data - Security considerations:

All form-processing software should treat user supplied form-data
with sensitivity, as it often contains confidential or personally
identifying information. There is widespread use of form "auto-fill" features in web browsers; these might be used to trick users to
unknowingly send confidential information when completing otherwise
innocuous tasks. multipart/form-data does not supply any features
for checking integrity, ensuring confidentiality, avoiding user
confusion, or other security features; those concerns must be
addressed by the form-filling and form-data-interpreting applications.

Applications that receive forms and process them must be careful not to supply data back to the requesting form-processing site that was not intended to be sent.

It is important when interpreting the filename of the Content-
Disposition header field to not inadvertently overwrite files in the
recipient's file space.

This concerns you if you are a developer and your server will process forms submitted by users which might end up containing sensitive information.

@Mark Amery 2019-02-03 09:51:29

The stuff about security after the most recent edit is all irrelevant to the question of what enctypes do. I know it's literally from the multipart/form-data RFC, but nonetheless it's an arbitrary dump of security considerations about submitting forms that are entirely orthogonal to whether data is sent as application/x-www-form-urlencoded or multipart/form-data.

@Premraj 2015-12-27 01:29:34

  • enctype(ENCode TYPE) attribute specifies how the form-data should be encoded when submitting it to the server.
  • multipart/form-data is one of the value of enctype attribute, which is used in form element that have a file upload. multi-part means form data divides into multiple parts and send to server.

@Yeo 2016-03-03 11:00:57

I believe enctype does not stand for encryption type. There is no encryption involved at this level. My guess is either encoding type or enclosed type. But surely it is not encryption type.

@Mark Amery 2019-02-02 14:55:13

Your final bullet point here about <head> and <body> is irrelevant and confusing.

@Rishad 2018-11-11 22:52:30

The enctype attribute specifies how the form-data should be encoded when submitting it to the server.

The enctype attribute can be used only if method="post".

No characters are encoded. This value is required when you are using forms that have a file upload control

From W3Schools

@Mark Amery 2019-02-02 14:22:56

This quote doesn't even mention multipart/form-data. It's also pretty unclear; what does the sentence "No characters are encoded" even mean? -1.

@Eric 2016-03-10 09:29:45

Usually this is when you have a POST form which needs to take a file upload as data... this will tell the server how it will encode the data transferred, in such case it won't get encoded because it will just transfer and upload the files to the server, Like for example when uploading an image or a pdf

@GP Singh 2013-07-04 09:13:25

enctype='multipart/form-data' means that no characters will be encoded. that is why this type is used while uploading files to server.
So multipart/form-data is used when a form requires binary data, like the contents of a file, to be uploaded

@sandy 2013-09-25 11:53:43

Set the method attribute to POST because file content can't be put inside a URL parameter using a form.

Set the value of enctype to multipart/form-data because the data will be split into multiple parts, one for each file plus one for the text of the form body that may be sent with them.

@underscore_d 2017-06-11 12:33:50

This implies that POST is likely to be sufficient for submitting a file via a form and that adding multipart/form-data is just a bonus in some vague way. That's not the case. Most files will absolutely require using multipart/form-data.

@Matt Asbury 2010-12-24 12:49:18

enctype='multipart/form-data is an encoding type that allows files to be sent through a POST. Quite simply, without this encoding the files cannot be sent through POST.

If you want to allow a user to upload a file via a form, you must use this enctype.

@Yugal Jindle 2013-08-27 00:01:37

So.. if the file is not a binary file then can we work without this ?

@Matt Asbury 2013-08-27 09:36:14

From what I understand, you can use multipart/form-data for sending non-binary files but it is inefficient. I believe using application/x-www-form-urlencoded is the correct way to send non-binary data but someone with more experience with non-binary files may need to correct me.

@Daniel Luna 2013-09-19 17:34:06

The main advantage to using multipart/form-data for sending a file is that it will work automatically in both frontend and backend. You don't have to do any special handling. All files are binary even if they should only contain text. application/x-www-form-urlencoded is the standard way to POST a form without attached files. multipart/form-data is the standard way to POST a form with attached file(s). (There are also numerous other encodings, such as application/json and application/json-patch+json, which are common for communication between server and client.)

@Arcabard 2014-07-14 22:46:14

Its worth pointing out you can base64 encode your image and send it as plain string data .

@Mark Amery 2019-02-02 14:29:02

Further to @Prospero's comment above: you can absolutely send files via POST without using multipart/form-data. What you can't do is do that using an ordinary HTML form submission, without JavaScript. Setting a form to use multipart/form-data is the only mechanism that HTML provides to let you POST files without using JavaScript. I feel like this isn't clear enough in the answer, and that a naive reader might think that the inability to send files without multipart/form-data is a limitation of HTTP; that's not the case.

Related Questions

Sponsored Content

19 Answered Questions

[SOLVED] Is it possible to apply CSS to half of a character?

19 Answered Questions

[SOLVED] Recommended way to embed PDF in HTML?

  • 2008-11-14 23:55:13
  • Daniel Silveira
  • 1262957 View
  • 1060 Score
  • 19 Answer
  • Tags:   html pdf

6 Answered Questions

[SOLVED] application/x-www-form-urlencoded or multipart/form-data?

14 Answered Questions

[SOLVED] <button> vs. <input type="button" />. Which to use?

21 Answered Questions

[SOLVED] What are valid values for the id attribute in HTML?

  • 2008-09-16 09:08:52
  • Mr Shark
  • 403473 View
  • 1843 Score
  • 21 Answer
  • Tags:   html

14 Answered Questions

[SOLVED] How can I select an element by name with jQuery?

2 Answered Questions

[SOLVED] Tool for sending multipart/form-data request

  • 2013-04-15 12:48:47
  • Valentin Despa
  • 362611 View
  • 453 Score
  • 2 Answer
  • Tags:   multipartform-data

2 Answered Questions

[SOLVED] What is http multipart request?

2 Answered Questions

[SOLVED] <select multiple> and enctype="multipart/form-data"

1 Answered Questions

Sponsored Content