Learning HTML 3.2 by Examples, section 5 Descriptions of HTML 3.2 tags:

INPUT - input fields in forms


To specify, within a form, input fields such as single line text fields, password fields, checkboxes, radio buttons, submit and reset buttons, hidden fields, file upload, image buttons, etc.

Typical rendering

Varies according to the field type.

Basic syntax

<INPUT TYPE=inputtype other_attributes>

Possible attributes

attribute name possible values meaning notes
NAME string name to be used to identify the field when submitting the contents to the server required for all but SUBMIT and RESET
VALUE string initial value of the input field; when TYPE is SUBMIT or RESET, provides a textual label obligatory, if TYPE is RADIO or CHECKBOX
CHECKED CHECKED when TYPE is RADIO or CHECKBOX, initializes the field to checked state  
SIZE integer visible size of the field, as number of average character widths  
MAXLENGTH integer maximum number of characters permitted in a text field default is: no limit
SRC URL address of an image for fields with background images
ALIGN TOP, MIDDLE, BOTTOM, LEFT, RIGHT image alignment for graphical submit buttons as ALIGN in IMG (and HTML 2.0 allows only TOP, MIDDLE, BOTTOM here, too); default is BOTTOM; this attribute is deprecated in HTML 4.0

The different values of the TYPE attribute correspond to different kinds of input fields as follows.

TYPE=TEXT (the default)

A single line text field whose visible size can be set using the SIZE attribute, e.g. SIZE=40 for a 40 characters wide field. Users should be able to type more than this limit though with the text scrolling through the field to keep the input cursor in view. You can enforce an upper limit on the number of characters that can be entered with the MAXLENGTH attribute. The NAME attribute is used to name the field, while the VALUE attribute can be used to initialize the text string shown in the field when the document is first loaded.

Notice that text input is restricted to a single line. Use the TEXTAREA element to define multi-line text fields.

Typically browsers display the field content (both the initial content and the content entered by a user) in a fixed font. Although an INPUT element may occur within text level markup, it is thus usually not affected by it.

In some situations, if the user terminates a line in a text input field, it may cause immediate form submission.


    <INPUT TYPE=TEXT SIZE=40 NAME=user value="your name">

This is like TYPE=TEXT but the browser should not echo the characters, so that people around the user will not see them. Typically, the browser uses a generic character like * to indicate that some character has been sent. The actual input is sent normally (without encryption!). You can use SIZE and MAXLENGTH attributes to control the visible and maximum length exactly as for regular text fields.




Used for simple Boolean attributes, or for attributes that can take multiple values at the same time. The latter is represented by several checkbox fields with the same NAME and a different VALUE attribute. Each checked checkbox generates a separate name/value pair in the submitted data, even if this results in duplicate names. You can use the CHECKED attribute to initialize the checkbox to its checked state.

Thus, a set of INPUT TYPE=CHECKBOX elements represents an n-of-many choice field, whereas a set of INPUT TYPE=RADIO elements represents a 1-of-many choice field. Cf. to the SELECT element.




Used for attributes which can take a single value from a set of alternatives. Each radio button field in the group should be given the same NAME attribute. Radio buttons require an explicit VALUE attribute. Only the checked radio button in the group generates a name/value pair in the submitted data.

One radio button in each group should be initially checked (thus providing a default value) using the CHECKED attribute. (The HTML 2.0 specification says that if this is not the case, the browser should check the first button initially. But HTML 3.2 requires that the form itself provide a CHECKED attribute for one of the fields.) Normally the default value should be a neutral value, often indicating that the user does not want to or cannot give the information requested. For more information about this, see my document Choices in HTML forms.

At all times, exactly one of the radio buttons in a set is checked; so if the user changes the selection, the browser must uncheck the button that was previously checked.


    <INPUT TYPE=RADIO NAME=age VALUE="?" CHECKED>unspecified<BR>
    <INPUT TYPE=RADIO NAME=age VALUE="0-12">0-12 years<BR>
    <INPUT TYPE=RADIO NAME=age VALUE="13-17">13-17 years<BR>
    <INPUT TYPE=RADIO NAME=age VALUE="18-25">18-25 years<BR>
    <INPUT TYPE=RADIO NAME=age VALUE="26-35">26-35 years<BR>
    <INPUT TYPE=RADIO NAME=age VALUE="36-">36 or more years<BR>


This defines a button or other presentation that users can select (e.g. by clicking) to submit the contents of the form to the server. A label is set for the button from the VALUE attribute. If the NAME attribute is given, then the name/value pair for the submit button will be included in the submitted data. You can include several submit buttons in the form. See TYPE=IMAGE for graphical submit buttons.


    <INPUT TYPE=SUBMIT VALUE="Party on ...">


This defines a button or other presentation that users can select (e.g. by clicking) to reset form fields to their initial state when the document was first loaded. You can set a label by providing a VALUE attribute. Reset buttons are never sent as part of the contents of a form.

It is customary to include a reset button after the submit button, but this means that if a user accidentally clicks on the wrong button, all information entered by him using the form is lost. So perhaps you should put the reset button somewhere else (if you include it at all). For a typical form, a reset button is rarely useful, since it is unlikely that the user wishes to clear all fields. However, a reset button might be useful if the form has e.g. prefilled text fields; see the fourth example in the description of the FORM element.


    <INPUT TYPE=RESET VALUE="Start over ...">

TYPE=FILE (Not in HTML 2.0!)

This provides a means for users to attach a file to the contents of the form.

This feature is not commonly supported yet. Notice that some browsers support it seemingly only, e.g. including the name of the file instead of its contents!

The element is generally rendered as a text field and an associated button or other presentation which, when selected (e.g. by clicking), invokes a file browser to select a file name. The file name can also be entered directly in the text field.

Just like for TYPE=TEXT you can use the SIZE attribute to set the visible width of this field in average character widths. You can set an upper limit to the length of file names using the MAXLENGTH attribute.

Some browsers support the ability to restrict the kinds of files (that can be attached to the contents of a form) using an ACCEPT attribute. The value of that attribute is a comma-separated list of MIME content types. For example, ACCEPT="image/*" would restrict files to images. Notice that the ACCEPT attribute is not defined in HTML 3.2, although it is defined in RFC 1867 to which the HTML 3.2 Reference Specification refers in this context for further information.

The value of the ENCTYPE attribute is an Internet media type which in this context specifies the data encoding used. The default is application/x-www-form-urlencoded (which is an unregistered type, but one that browsers are required to support). Another type which browsers should support is multipart/form-data (see RFC 1867). Browsers may support other media types in this context, too.

Further information on using forms for file upload can be found in RFC 1867. See also item How can I allow file uploads to my web site? in the WDG Web Authoring FAQ and my detailed document File input (or "upload") in HTML forms.




This indicates that the field should not be rendered to the user. A hidden field provides a means for servers to store state information with a form. This will be passed back to the server when the form is submitted, using the name/value pair defined by the corresponding attributes. This is a workaround for the statefulness of HTTP and an alternative to using so-called HTTP cookies.


    <INPUT TYPE=HIDDEN NAME=customerid VALUE="c2415-345-8563">


This acts as a submit button (cf. TYPE=SUBMIT), but it is rendered by an image rather than a text string and the form is submitted so that information about the clicked location is passed, too. The URL for the image is specified with the SRC attribute. The image alignment can be specified with the ALIGN attribute. In this respect, graphical submit buttons are treated identically to IMG elements (so you can set ALIGN to LEFT, RIGHT, TOP, MIDDLE or BOTTOM). A NAME attribute is required. When the user clicks on the button, the x and y coordinates of the location clicked are passed to the server is two name/value pairs. The names are derived by taking the name of the field and appending .x for the x value and .y for the y value.


<P>Now choose a point on the map:
<INPUT TYPE=IMAGE SRC="map.gif" NAME="point">
Notice that image fields cause problems to people using text-only or speech-based user agents or graphical browsers with automatic loading of images disabled.

The specifications do not mention the VALUE attribute for INPUT TYPE=IMAGE, but at least one text-mode browser takes its value it as the substitute for the image. Thus, defining a meaningful VALUE attribute is good idea, if the form makes sense even if the script processing it does not get (meaningful) x and y values. For more information, see Alan Flavell's INPUT TYPE=IMAGE for text users?

Allowed context

Text container, i.e. any element that may contain text elements. This includes most HTML elements. However, the text container must appear within a FORM element.




<INPUT TYPE=RESET VALUE="Start over ...">


See the description of the FORM element, which contains some examples of entire forms.

The use of INPUT for text input is restricted to single line fields. Use TEXTAREA to define multi-line text fields.

Date of last update: 2010-12-16.
This page belongs to the free information site IT and communication, section Web authoring and surfing, by Jukka "Yucca" Korpela.