The HTML <input> Element

Basic

The <input> element creates a form control for a typed piece of data. It is one element with many states: the type attribute changes the kind of value, interaction, validation behavior, and user interface the browser provides. Learning <input> well therefore means learning both the element itself and the rules of its individual states.

What the <input> element represents

An <input> is a void element: it has a start tag and no end tag, and it cannot contain child content. It is normally used where phrasing content is allowed. Most input states are interactive, labelable, submittable, and associated with a form; the hidden state is a special case.

<label for="email">Email</label>
<input id="email" name="email" type="email">

<input name="email" type="?">

?

The element has no single universal user interface. The type attribute selects an input state, while attributes such as name, value, required, autocomplete, min, max, step, pattern, multiple, accept, and list refine that state.

Start with the default: text

If type is omitted or has an unknown value, the input uses the Text state. A text input accepts a single line of text. Use it when the value is genuinely free-form text and no more specific input state better describes what the user is entering.

<label for="username">Username</label>
<input id="username" name="username" type="text">

The text state supports useful constraints and hints such as maxlength, minlength, pattern, placeholder, readonly, required, size, autocomplete, and list. The placeholder is a hint, not a replacement for a visible label.

The input type family

The HTML Standard defines distinct input states. Choosing the state is semantic: it tells the browser what kind of data is expected and allows an appropriate control, keyboard, validation model, autofill behavior, or picker to be offered.

• hidden — carries a value without presenting an interactive control.

• text — single-line free-form text.

• search — search-oriented text control.

• tel — telephone-number text control.

• url — URL input with URL-oriented validation.

• email — email address or, with multiple, a comma-separated list of addresses.

• password — single-line sensitive text entry with obscured presentation.

• date — calendar date without a time zone.

• month — year and month.

• week — calendar week and year.

• time — time without a date.

• datetime-local — local date and time without a time zone.

• number — numeric value with min, max, and step semantics.

• range — numeric value represented as a slider-like control.

• color — color selection control.

• checkbox — independently selectable boolean option.

• radio — one choice within a radio group.

• file — file-selection control.

• submit — form-submission button.

• image — image submit button with coordinate data.

• reset — form-reset button.

• button — push button with no default form submission or reset behavior.

Text-like states: search, tel, url, email, password

The search, tel, url, email, and password states all collect text, but they communicate different intent. Search is for search terms; tel is for telephone numbers; url is for URLs; email is for email addresses; password is for sensitive text entry. These states can also influence virtual keyboards, autofill, validation, and platform UI.

<input type="search" name="q" aria-label="Search">
<input type="tel" name="phone" autocomplete="tel">
<input type="url" name="homepage" autocomplete="url">
<input type="email" name="email" autocomplete="email">
<input type="password" name="password" autocomplete="current-password">

Do not use type="text" everywhere simply because server-side validation exists. Native semantics are useful before submission, during autofill, and on touch devices. They complement rather than replace server-side validation.

Dates and times

The date, month, week, time, and datetime-local states represent structured temporal values. They are not interchangeable strings. In particular, datetime-local represents a local date and time and does not encode a time zone.

<input type="date" name="start-date">
<input type="month" name="billing-month">
<input type="week" name="release-week">
<input type="time" name="opening-time">
<input type="datetime-local" name="meeting">

Browser interfaces for these states vary by platform. HTML defines the value model and constraints; it does not require every browser to display the same calendar or clock widget.

Numeric states: number and range

The number state represents a number. Its min, max, and step attributes define constraints and stepping behavior. The range state represents a numeric value selected from a range and is generally presented as a slider-like control.

<label for="quantity">Quantity</label>
<input id="quantity" name="quantity" type="number" min="1" max="20" step="1">

<label for="volume">Volume</label>
<input id="volume" name="volume" type="range" min="0" max="100" step="1" value="50">

Do not assume number means "digits only" in every circumstance or that range is interchangeable with number. Their semantics, UI, constraint behavior, and intended interaction differ.

Color

The color state represents a color value. Browsers may provide a color picker or another native color-selection interface. The HTML value model is more important than any particular picker design.

<label for="accent">Accent color</label>
<input id="accent" name="accent" type="color" value="#3366ff">

Current HTML also defines color-related attributes such as alpha and colorspace. Treat these as standards-level features and verify browser support before depending on them in production.

Checkboxes and radio buttons

Checkboxes represent independently selectable options. Radio buttons represent choices in a group where the same name identifies the group and only one member is selected at a time through normal user interaction.

<fieldset>
  <legend>Topics</legend>
  <label><input type="checkbox" name="topic" value="html"> HTML</label>
  <label><input type="checkbox" name="topic" value="css"> CSS</label>
</fieldset>

<fieldset>
  <legend>Plan</legend>
  <label><input type="radio" name="plan" value="free"> Free</label>
  <label><input type="radio" name="plan" value="pro"> Pro</label>
</fieldset>

The checked attribute establishes the initial checked state in markup. JavaScript can also expose an independent indeterminate state for checkboxes; indeterminate is a runtime property, not a third submitted checkbox value.

File inputs

The file state lets the user choose files through a browser-controlled picker. The accept attribute can provide hints about expected file types, and multiple allows multiple files to be selected. The browser does not give a page arbitrary filesystem access simply because an input is type="file".

<label for="avatar">Profile photo</label>
<input id="avatar" name="avatar" type="file" accept="image/*">

<label for="documents">Documents</label>
<input id="documents" name="documents" type="file" multiple>

When files are submitted, the form encoding and server-side handling matter. Client-side accept filtering is a hint to the picker, not a security boundary; the server must validate uploaded content.

Button states: submit, image, reset, button

The input element also has button-like states. submit submits the form; reset restores controls to their initial values; button is a generic push button with no default form submission or reset action; image is an image-based submit button and can contribute click coordinates to form data.

<input type="submit" value="Save">
<input type="reset" value="Clear">
<input type="button" value="Show details">
<input type="image" src="/images/map-submit.png" alt="Choose location">

For ordinary action buttons, the <button> element is usually the clearer authoring choice because its label comes from its contents and it can contain phrasing content. The input button states remain part of the HTML input vocabulary and are important when reading or maintaining existing documents.

name, id, and value are different

The id identifies an element in the document and is commonly used by label for and scripting. The name identifies the form-control name used in form submission and APIs such as form.elements. The value represents the control value, with its precise meaning depending on the input state.

<label for="country">Country</label>
<input id="country" name="country" type="text" value="Egypt">

A control can have an id without a name and still be addressable in the document, but a successful form control generally needs an appropriate name to contribute its data during form submission. The exact submission rules vary by input state.

Labels and accessible names

Labelable input controls should have an appropriate accessible name. The label element is the normal HTML mechanism for giving a visible form control its user-facing label. A label can explicitly reference an input with for and id, or it can contain the control.

<label for="email">Email address</label>
<input id="email" name="email" type="email">

<label>
  Email address
  <input name="email" type="email">
</label>

Form association

An input normally belongs to its nearest ancestor form. Listed form-associated inputs can use the form attribute to explicitly associate themselves with a form elsewhere in the document. The value of form is the id of the form element.

<form id="profile" action="/profile" method="post">
  <label for="display-name">Display name</label>
  <input id="display-name" name="displayName">
</form>

<input form="profile" name="timezone" value="Africa/Cairo">

The form attribute changes the form owner; it does not mean the input becomes a child of that form in the DOM. This distinction matters when document structure, CSS, scripting, and form behavior are considered together.

Common input attributes

• autocomplete — provides a hint for autofill behavior.

• placeholder — provides a short hint about expected input; it is not a label.

• required — marks a control as required for constraint validation when that state supports it.

• readonly — makes supported values non-editable while retaining different submission semantics from disabled.

• disabled — prevents user interaction and excludes the control from normal form submission.

• minlength and maxlength — constrain supported text lengths.

• pattern — supplies a regular-expression constraint for supported text-like states.

• min, max, and step — constrain and describe stepping for supported numeric and temporal states.

• multiple — permits multiple values where the input state supports it, such as email and file.

• list — associates supported input states with a datalist by id.

• accept — provides a file-type hint for file inputs.

• checked — establishes the initial checked state for checkbox and radio inputs.

• alt — supplies alternative text for image submit controls.

• size — controls the intended display width of supported text-like controls.

• form — explicitly sets the form owner for listed form-associated inputs.

Attributes are state-dependent

One of the hardest parts of <input> is that attributes do not apply uniformly to every state. For example, maxlength makes sense for text entry but not for a color picker; min and step are meaningful for number but not for ordinary text; accept applies to file; checked applies to checkbox and radio.

Treat the input type and its state-specific rules as a contract. Do not copy an attribute set from one input type to another and assume the browser will interpret every attribute.

Constraint validation belongs to the input state

Many input states participate in native constraint validation. required, pattern, min, max, step, minlength, maxlength, and type-specific validity rules can contribute to whether a control is valid. The details vary by state.

This lesson establishes what the input element and its states can express. The curriculum will cover the validation API, validation flow, user feedback, and server-side validation as a separate cross-element Form Validation lesson.

The value model and JavaScript

JavaScript interacts with input through HTMLInputElement. The value property exposes the control value, while some states provide additional IDL properties such as valueAsNumber, valueAsDate, files, checked, or selection APIs. Which properties apply depends on the state.

const input = document.querySelector("#age");
console.log(input.value);
console.log(input.valueAsNumber);

The input event reports user-driven value changes for supported controls, while change reports a committed change according to the control state. Script should use the APIs appropriate to the specific input state rather than treating every input as a plain string field.

Deep model: content value, dirty value, and checkedness

The HTML Standard distinguishes the value represented by an input element from the user’s current editing state. Text-entry controls have a dirty value flag, and checkbox controls have checkedness plus an independent indeterminate state. These concepts explain why changing an HTML value attribute is not always the same thing as changing the live control value through JavaScript.

This distinction becomes important when resetting forms, synchronizing application state, inspecting controls through the DOM, and debugging code that mixes HTML attributes with IDL properties.

Choosing the right input state

• Start with the data you actually need to collect, not the visual widget you want.

• Prefer a specific state such as email, url, date, number, or file when its semantics match the value.

• Use text only when the value is genuinely general single-line text.

• Use checkbox for independent yes/no or multi-select choices and radio for mutually exclusive choices.

• Use number or range only when a numeric model is actually appropriate.

• Use password for secrets and pair it with appropriate autocomplete tokens.

• Use file for file selection; never treat client-side file hints as security validation.

• Give labelable controls a clear accessible name and use name when their value should participate in form submission.

Common mistakes

• Using type="text" for every value even when a more specific state exists.

• Treating placeholder text as the control label.

• Forgetting name and then wondering why a value is absent from submitted form data.

• Assuming disabled and readonly have identical submission behavior.

• Assuming min, max, pattern, or maxlength applies to every input type.

• Using accept as a security mechanism for uploaded files.

• Assuming browser date, time, or color widgets look the same everywhere.

• Treating the value attribute as though it were always the current live value.

• Using a radio group without giving related radios the same name.

• Building a custom widget when a native input state already provides the needed semantics and interaction.

From beginner to expert

At beginner level, you should be able to choose an appropriate type, connect a label, provide a useful name, and build common controls. At intermediate level, you should understand state-specific attributes, form ownership, native constraints, autofill, and the differences between checkbox, radio, numeric, temporal, file, and text states. At advanced level, you should be able to reason about successful controls, state-dependent applicability, value and checkedness, DOM properties, browser UI variability, accessibility, security boundaries, and how the input element participates in the larger form-control infrastructure.

Practical checklist

• Choose the input type from the data semantics.

• Give the control a clear label or other appropriate accessible name.

• Use id for document association and name for form data when needed.

• Use state-appropriate attributes rather than a generic attribute bundle.

• Add autocomplete tokens when autofill can help users.

• Use native constraints where they improve the user experience, while still validating data on the server.

• Test keyboard, touch, screen-reader, autofill, and mobile input behavior for important forms.

• Remember that browser-native widgets are not guaranteed to look identical across platforms.