What does enctype multipart form-data mean

Question

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  lt form gt s    When a form is submitted  an HTTP Request is 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    Security  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

User · Answer

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

User · Answer

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

User · Answer

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    application x-www-form-urlencoded multipart form-data  spec points to RFC7578  text plain  This is  not reliably interpretable by computer   so it should never be used in production  and we will not look further into it    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    nc -l or an ECHO server  HTTP test server accepting GET POST requests an user agent like a browser or cURL   Save the form to a minimal  html file    lt  DOCTYPE html gt   lt html lang  en  gt   lt head gt     lt meta charset  utf-8   gt     lt title gt upload lt  title gt   lt  head gt   lt body gt   lt form action  http   localhost 8000  method  post  enctype  multipart form-data  gt     lt p gt  lt input type  text  name  text1  value  text default  gt     lt p gt  lt input type  text  name  text2  value  a amp  x03C9 b  gt     lt p gt  lt input type  file  name  file1  gt     lt p gt  lt input type  file  name  file2  gt     lt p gt  lt input type  file  name  file3  gt     lt p gt  lt button type  submit  gt Submit lt  button gt   lt  form gt   lt  body gt   lt  html gt    We set the default text value to a amp  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    gt  a txt  echo   lt  DOCTYPE html gt  lt title gt Content of a html  lt  title gt    gt  a html    Binary file containing 4 bytes   a   1  2 and  b   printf  a xCF x89b   gt  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   multipart form-data  Firefox sent   POST   HTTP 1 1    Less interesting headers        Content-Type  multipart form-data  boundary ---------------------------735323031399963166993862150 Content-Length  834  -----------------------------735323031399963166993862150 Content-Disposition  form-data  name  text1   text default -----------------------------735323031399963166993862150 Content-Disposition  form-data  name  text2   a b -----------------------------735323031399963166993862150 Content-Disposition  form-data  name  file1   filename  a txt  Content-Type  text plain  Content of a txt   -----------------------------735323031399963166993862150 Content-Disposition  form-data  name  file2   filename  a html  Content-Type  text html   lt  DOCTYPE html gt  lt title gt Content of a html  lt  title gt   -----------------------------735323031399963166993862150 Content-Disposition  form-data  name  file3   filename  binary  Content-Type  application octet-stream  a b -----------------------------735323031399963166993862150--   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 ---------------------------735323031399963166993862150 sets the content type to multipart form-data and says that the fields are separated by the given boundary string   But note that the   boundary ---------------------------735323031399963166993862150   has two less dadhes -- than the actual barrier  -----------------------------735323031399963166993862150   This is because the standard requires the boundary to start with two dashes --  The other dashes appear to be just how Firefox chose to implement the arbitrary boundary  RFC 7578 clearly mentions that those two leading dashes -- are required      4 1    Boundary  Parameter of multipart form-data      As with other multipart types  the parts are delimited with a   boundary delimiter  constructed using CRLF   --   and the value of   the  boundary  parameter   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  https   cs stackexchange com questions 39687 find-the-shortest-sequence-that-is-not-a-sub-sequence-of-a-set-of-sequences 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    application x-www-form-urlencoded  Now change the enctype to application x-www-form-urlencoded  reload the browser  and resubmit   Firefox sent   POST   HTTP 1 1    Less interesting headers        Content-Type  application x-www-form-urlencoded Content-Length  51  text1 text default amp text2 a CF 89b amp file1 a txt amp file2 a html amp file3 binary   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   Comparison  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   amp    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

User · Answer

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  JSON is a common format for use with web services and some still use SOAP    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  lt input type  file  gt  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- gt 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 that 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 Network Panel in the developer tools of most browsers  are better for that

[html] What does enctype='multipart/form-data' mean?

Examples related to html

Examples related to http-headers

Examples related to multipartform-data