Why not use enctype="multipart/form-data" always?

TL; DR

There's almost certainly no problem if you're targeting any modern browser and using SSL for any confidential data.

Background

The form-data type was originally developed as an experimental extension for file uploads in browsers, as explained in rfc 1867. There were compatibility issues at the time, but if your target browsers supports HTML 4.x and hence the enc-type, you're fine. As you can see here that's not an issue for all mainstream browsers.

As already noted in other answers, it is a more verbose format, but that is also not an issue when you can compress the request or even just rely on the improved speed of communications in the last 20 years.

Finally, you should also consider the potential for abuse of this format. Since it was designed to upload files, there was the potential for this to be used to extract information from the user's machine without their knowledge, or sending confidential information unencrypted, as noted in the HTML spec. Once again, though, modern browsers are so field hardened, I would be stunned if such low hanging fruit was left for hackers to abuse and you can use HTTPS for confidential data.

There's a bit of overhead with using multipart/form-data for simple text forms. Compare a simple form with name and email.

Default (x-www-form-urlencoded)

Content-Type: application/x-www-form-urlencoded; charset=utf-8

name=Nomen+Nescio&email=foo%40bar.com

multipart/form-data

Content-Type: multipart/form-data; boundary=96a188ad5f9d4026822dacbdde47f43f

--96a188ad5f9d4026822dacbdde47f43f
Content-Disposition: form-data; name="name"

Nomen Nescio
--96a188ad5f9d4026822dacbdde47f43f
Content-Disposition: form-data; name="email"

[email protected]
--96a188ad5f9d4026822dacbdde47f43f

As you can see, you need to transmit a bunch of additional bytes in the body when using multipart encoding (37 bytes vs 252 bytes in this example)

But when you add the http headers and apply compression, the relative difference in payload would in most real life cases be much smaller.

The reason to prefer urlencoded over multipart is a small saving in http request size.

From the RFC that defines multipart/form-data:

Many web applications use the "application/x-www-form-urlencoded" method for returning data from forms. This format is quite compact, for example:

name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send

However, there is no opportunity to label the enclosed data with a content type, apply a charset, or use other encoding mechanisms.

Many form-interpreting programs (primarily web browsers) now implement and generate multipart/form-data, but a receiving application might also need to support the "application/x-www-form-urlencoded" format.

Aside from letting you upload files, multipart/form-data also allows you to use other charsets and encoding mechanisms. So the only reasons not to use it are:

• If you want to save a bit of bandwidth (bearing in mind that this becomes much less of an issue if the request body is compressed).

• If you need to support really old clients that can't handle file uploads and only know application/x-www-form-urlencoded, or that have issues handling anything other than ASCII.