Input Controls

Know the full range of <input> type values, group them by purpose, and choose the specific type that gives users the best editing experience and gives you built-in validation for free.

The <input> element is a chameleon — a single tag that becomes a text box, a password field, a calendar picker, a slider, a color swatch, or a file uploader, all depending on its type attribute. Beginners often reach for type="text" out of habit for everything, but HTML5 gives you around twenty specialized input types, and picking the right one is not a cosmetic choice. The correct type triggers the right mobile keyboard, gives the browser built-in validation rules for free, and communicates intent clearly to assistive technology.

Text-like inputs

This group covers free-form and semi-structured text entry. text is the general-purpose default for names, addresses, and anything without a stricter shape. password masks each character as it's typed and prevents the browser from showing it in plain view. email validates that the entered value looks like an email address (something@something) before the form is even allowed to submit, and on mobile it swaps in a keyboard with an '@' key front and center. tel accepts phone numbers — it doesn't enforce a format (phone formats vary too much worldwide), but it does trigger a numeric phone keypad on mobile. url validates that the value is a well-formed URL and gets a keyboard with '/' and '.com' shortcuts. search looks like a text input but is styled with search semantics in mind (some browsers add a small 'x' to clear it) and is meant for search boxes.

• text • password • email • tel • url • search

Date and time inputs

Rather than asking users to type '09/14/2026' into a plain text box and hoping the format matches what your code expects, HTML5 gives you native date and time pickers. date opens a calendar widget and returns a value in YYYY-MM-DD format. time picks an hour and minute. datetime-local combines both, useful for scheduling. month and week are narrower pickers for selecting just a year+month or a year+week number, handy for billing cycles or reporting periods. All of these hand off the fiddly work of parsing and formatting dates to the browser instead of your JavaScript.

• date • time • datetime-local • month • week

Choice and range inputs

color opens a color-picker swatch and returns a hex value like #ff6600. range renders a draggable slider between a min and max — ideal for a volume control or a price filter where the exact number matters less than the relative position. checkbox lets a user toggle one option on or off independently; several checkboxes sharing the same name let a user pick any number of options from a set. radio lets a user pick exactly one option from a group — and radios only behave as a mutually-exclusive group when they all share the same name attribute. file opens the operating system's file picker for uploads. hidden stores a value that travels with the form but is never shown or editable by the user — commonly used for things like a CSRF token or a record ID.

• color • range • checkbox • radio • file • hidden

Action inputs

A smaller group of input types don't collect data at all — they trigger an action. submit renders a button that submits the enclosing form. reset renders a button that clears the form back to its default values. button renders a plain clickable button with no built-in form behavior at all, meant to be wired up to custom JavaScript. In modern HTML, the <button> element is generally preferred over input type="submit"/"button" because it can contain rich content like icons and nested markup, but input versions still appear often enough that you should recognize them.

• submit • reset • button

number as its own category

type="number" deserves a special mention: it restricts entry to numeric values, adds small increment/decrement spinner arrows, and on mobile pulls up a numeric keypad. It also supports min, max, and step attributes for constraining the range and increment, which you'll see in more depth in the validation lesson.

Why the specific type matters

Two benefits come free just from picking the accurate type. First, built-in validation: type="email" rejects a value with no '@' before the form can even be submitted, and type="number" won't accept letters — no custom JavaScript required. Second, better mobile ergonomics: phones and tablets detect the input type and swap in a matching on-screen keyboard, so type="tel" shows a phone dial pad and type="email" surfaces the '@' key, saving users real time and taps. Using type="text" for everything throws both of these benefits away.

The type attribute pattern

The type attribute is what turns a generic <input> into a specialized control. Every type still needs a name attribute to be included in the submitted data.

<input type="email" name="userEmail">
<input type="number" name="quantity" min="1" max="10">
<input type="date" name="birthday">

Code Examples

Each field uses the type that matches its content. The email field gets automatic format validation; the tel field triggers a numeric dial-pad keyboard on mobile even though phone numbers themselves aren't format-validated.

Native date and time pickers guarantee a consistent, parseable value (like 2026-09-14 and 14:30) regardless of the user's locale or typing habits, instead of trusting free-text input to be formatted correctly.

The radios share name="plan", which is what makes them mutually exclusive — selecting 'Pro' automatically deselects 'Basic'. The checkboxes share a name too, but checkboxes don't exclude each other; a user can check both 'HTML' and 'CSS'.

name="plan" shared across radios enforces single-choice behavior

Both fields will accept literally anything — 'not-an-email' passes the email field, and 'twelve' passes the age field. Switching to type="email" and type="number" gives you real validation and better mobile keyboards at zero extra cost.

Common mistake: Defaulting to type="text" for data that has a more specific, purpose-built type available.

<input type="text" name="fullName" placeholder="Full name">
<input type="email" name="email" placeholder="[email protected]">
<input type="tel" name="phone" placeholder="(555) 555-5555">

<input type="date" name="eventDate">
<input type="time" name="eventTime">

<!-- Pick exactly one -->
<input type="radio" name="plan" value="basic"> Basic
<input type="radio" name="plan" value="pro"> Pro

<!-- Pick any number -->
<input type="checkbox" name="topics" value="html"> HTML
<input type="checkbox" name="topics" value="css"> CSS

<input type="text" name="email">
<input type="text" name="age">

Input type families

Grouping the ~20 input types by purpose makes them far easier to remember than a flat alphabetical list.

Text-like (text, email, tel, url, search, password)
Date/Time  (date, time, datetime-local, month, week)
Choice     (checkbox, radio, color, range, file, hidden)
Action     (submit, reset, button)

Important Rules

Choose the input type that matches the data's real shape — it's free validation and a better mobile keyboard.

Radios only act as a mutually-exclusive group when every radio in the group shares the same name.

Checkboxes sharing a name allow multiple selections; radios sharing a name allow only one.

hidden inputs still need a name and value — they submit like any other input, just without a visible control.

Why this matters in practice

E-commerce checkout forms are a good showcase: type="tel" for a phone number pulls up a numeric keypad instead of a full QWERTY keyboard, type="email" catches a missing '@' before the order is even submitted, and type="date" for a delivery preference avoids the classic ambiguity between MM/DD/YYYY and DD/MM/YYYY that free-text date fields create.

<input type="radio" name="size"> Small <input type="radio" name="sizeOption"> Large

<input type="radio" name="size"> Small <input type="radio" name="size"> Large

Giving the two radios different names breaks the mutual-exclusivity grouping — both could end up selected at once, since the browser only groups radios that share an identical name.

[Multiple Choice] A form has two checkboxes for 'Email me updates' and 'Subscribe to newsletter', and the developer wants a user to be able to check both at once, independently. What must be true about their name attributes? A. They must share the exact same name, since only same-named controls submit together B. They must each have a distinct name — sharing a name would let the browser force them into mutual exclusivity like radios C. They should each have distinct names so both can be independently checked, since checkboxes never exclude each other regardless of shared names, but distinct names keep their submitted values clearly separated D. Checkboxes cannot be independently toggled if they appear in the same form

C. They should each have distinct names so both can be independently checked, since checkboxes never exclude each other regardless of shared names, but distinct names keep their submitted values clearly separated — Checkboxes never enforce mutual exclusivity, even when they share a name (shared-name checkboxes just submit as a list of values for that name). But giving each checkbox its own distinct name keeps their submitted data cleanly separated as two independent fields, which is the more common and predictable pattern for unrelated toggles.

Add a quantity field (1 to 20) and a favorite color field to a product order form, using the most appropriate input types.

One of HTML5's numeric types supports min/max attributes directly; one input type opens a color swatch picker.