Forms & inputs

The markup side of forms: the <form> element and how submission works, every input type and attribute, labels and groups, buttons, select, textarea and friends, autofill tokens, mobile keyboards, built-in validation, file uploads and the accessibility rules. Reading values, FormData, the constraint validation API and fetch submission are in Forms (TypeScript); styling controls is in CSS; form layout and copy advice is in UX & UI.

The form element

<form action="/signup" method="post">
  <label for="email">Email</label>
  <input id="email" name="email" type="email"
    autocomplete="email" required>
  <button>Create account</button>
</form>

Controls outside the form join it with form="form-id", and a submit button can override the form's settings for its own click with formaction, formmethod, formenctype, formnovalidate and formtarget (for example a "Save draft" button that skips validation).

Implicit submission

Pressing Enter in a text-like field submits the form by "clicking" its default button: the first submit button in tree order.

Text-like here means text, search, url, tel, email, password, number and the date and time types. So a form with only an icon-less "Next" <div> can't be submitted from the keyboard: always include a real submit button, even if it's visually hidden.

What gets submitted

The browser builds a list of name/value pairs from the form's controls, in tree order:

<form method="get" action="/search">   →   GET /search?q=red+shoes&size=9&size=10&sort=price
 
POST, application/x-www-form-urlencoded:
  email=sam%40acme.example&plan=pro&tags=ci&tags=perf
  (UTF-8, percent-encoded; spaces become +; newlines become %0D%0A)
 
POST, multipart/form-data:
  ------boundary
  Content-Disposition: form-data; name="title"
 
  Holiday
  ------boundary
  Content-Disposition: form-data; name="photo"; filename="beach.jpg"
  Content-Type: image/jpeg
 
  (binary bytes)
  ------boundary--

Input types

The date and time types are Baseline widely available; month and week are not. Where a type isn't supported the browser falls back to type="text", so server-side validation is required anyway.

<style>
  form { display: grid; gap: 6px 12px;
    grid-template-columns: max-content 1fr; }
  input { font: inherit; justify-self: start; }
</style>
<form>
  <label for="d">date</label>
  <input id="d" type="date" value="2026-09-26">
  <label for="t">time</label>
  <input id="t" type="time" value="14:30">
  <label for="dl">datetime-local</label>
  <input id="dl" type="datetime-local"
    value="2026-09-26T14:30">
  <label for="c">color</label>
  <input id="c" type="color" value="#1f6feb">
  <label for="r">range</label>
  <input id="r" type="range" min="0" max="10" value="7">
  <label for="n">number</label>
  <input id="n" type="number" min="0" max="9" value="3">
  <label for="s">search</label>
  <input id="s" type="search" value="red shoes">
</form>

Input attributes

pattern

<input name="postcode" pattern="[A-Za-z0-9 ]{5,8}"
  title="5 to 8 letters, digits or spaces">
<input name="slug" pattern="[a-z0-9\-]+">

• Implicitly anchored: the browser wraps it as ^(?:pattern)$, so it must match the whole value. Don't add ^ and $.
• Compiled with the v flag since mid-2023 (MDN; previously u). In v mode, -, (, ), [, ], {, }, / and | must be escaped inside a character class: [\w-] is now a syntax error. An invalid pattern is silently ignored (a console warning only), so every value passes.
• Empty values pass pattern; add required to forbid them.
• Some browsers show the title in the validation bubble. Put the rule in visible hint text too.

readonly vs disabled

Labels, fieldsets & groups

<!-- explicit: for + id (works anywhere in the document) -->
<label for="name">Full name</label>
<input id="name" name="name" autocomplete="name">
 
<!-- implicit: wrap the control -->
<label>
  <input type="checkbox" name="terms" required>
  I accept the <a href="/terms/">terms</a>
</label>

fieldset + legend group related controls: the legend is announced as the group's name when a screen-reader user enters it. Use them for radio groups, checkbox groups, and composite fields such as an address or a date of birth.

• legend must be the first child of fieldset.
• <fieldset disabled> disables every control inside except those in its legend.
• Keep legends short (they may be repeated for every field in some screen readers); put long instructions in a paragraph referenced with aria-describedby on the fieldset.

<style>
  fieldset { border: 1px solid var(--chip);
    border-radius: 6px; padding: 8px 12px; }
  label { display: block; padding: 3px 0; }
  .hint { color: var(--muted); margin: 0 0 4px; }
</style>
<fieldset aria-describedby="plan-hint">
  <legend>Plan</legend>
  <p id="plan-hint" class="hint">Change it any time.</p>
  <label><input type="radio" name="plan" value="free"
    checked> Free</label>
  <label><input type="radio" name="plan" value="pro">
    Pro, £8 a month</label>
  <label><input type="radio" name="plan" value="team"
    disabled> Team (coming soon)</label>
</fieldset>

Tab moves into the group (to the checked radio) and the arrow keys move between options. A group of checkboxes, by contrast, is one tab stop per box.

Buttons

• Label buttons with the action: "Create account", "Save changes", not "Submit" or "OK".
• A button that only shows an icon needs a text alternative: visually hidden text or aria-label.
• Don't disable the submit button until the form is valid; users can't discover what's missing. Disable it (or ignore repeat clicks) only while a submission is in flight.

select, datalist & textarea

select

<label for="country">Country</label>
<select id="country" name="country" required
  autocomplete="country">
  <option value="">Choose a country…</option>
  <optgroup label="Europe">
    <option value="GB">United Kingdom</option>
    <option value="IE">Ireland</option>
  </optgroup>
  <hr>
  <option value="other">Other</option>
</select>

Customizable select. appearance: base-select on the select and on ::picker(select) opts into a fully stylable control: options can hold rich markup (icons, descriptions), a <button> child replaces the trigger, <selectedcontent> mirrors the chosen option, and the picker is positioned in the top layer with anchor positioning. As of September 2026 it ships in Chrome and Edge 135+ and Safari 27 (released September 2026); Firefox has it only behind a flag, so it is not Baseline. It is a progressive enhancement: browsers without it render a normal native select, so it is safe to use today.

select, ::picker(select) {
  appearance: base-select;
}
select::picker-icon { transition: rotate 0.2s; }
select:open::picker-icon { rotate: 180deg; }
option:checked { font-weight: 600; }

datalist

Suggestions, not constraints: the user can still type anything.

<label for="browser">Browser</label>
<input id="browser" name="browser" list="browsers">
<datalist id="browsers">
  <option value="Chrome"></option>
  <option value="Firefox"></option>
  <option value="Safari"></option>
</datalist>

Support is patchy for non-text types (no Firefox for date, time or color), the popup can't be styled, and it is only partly supported in Firefox for Android. Fine for low-stakes hints; use a real combobox when choosing from the list matters.

textarea

<label for="msg">Message</label>
<textarea id="msg" name="msg" rows="4" maxlength="2000"
  aria-describedby="msg-hint"></textarea>
<p id="msg-hint">Up to 2,000 characters.</p>

<style>
  textarea { font: inherit; inline-size: 100%;
    field-sizing: content; min-block-size: 2lh;
    max-block-size: 6lh; resize: vertical; }
</style>
<label for="note">Note (grows as you type, up to 6
  lines, where supported)</label>
<textarea id="note">Type a few more lines here…</textarea>

output, progress & meter

Use progress for "uploading 40 %" and meter for "disk 90 % full" or a score. The browser colors a meter by which region value falls in relative to optimum. Both need a label and the value in text: their visual state alone isn't reliable for everyone.

<style>
  p { display: flex; align-items: center; gap: 8px;
    margin: 6px 0; }
  label { inline-size: 9ch; }
</style>
<p><label for="up">Upload</label>
  <progress id="up" value="40" max="100"></progress> 40 %</p>
<p><label for="wait">Loading</label>
  <progress id="wait"></progress> indeterminate</p>
<p><label for="disk">Disk</label>
  <meter id="disk" value="0.9" low="0.6" high="0.8"
    optimum="0.2"></meter> 90 % full</p>

Autocomplete tokens

The autocomplete attribute tells browsers and password managers exactly what a field holds. It makes autofill fill the right fields, lets password managers save and suggest correctly, lets iOS offer SMS codes, and satisfies WCAG 1.3.5 Identify Input Purpose (AA). Browsers largely ignore autocomplete="off" on login fields, so fighting autofill fails; label fields properly instead.

<input name="ship-zip"
  autocomplete="shipping postal-code">
<input name="user"
  autocomplete="username webauthn">

Keyboards: inputmode & enterkeyhint

inputmode changes the on-screen keyboard without changing validation or value handling, which makes type="text" inputmode="numeric" the right choice for codes, card numbers and postcodes.

enterkeyhint sets the Enter key's label: enter, done, go, next, previous, search, send. It changes only the label, not the behavior; use next on fields that are not last and send on a chat box. Both attributes are Baseline widely available.

Built-in validation

On submit (unless the form has novalidate or the button formnovalidate), the browser checks each control's constraints, cancels the submission if any fail, focuses the first invalid one and shows a message bubble. The bubble can't be styled, its wording varies by browser and language, it disappears after a few seconds, and only one error shows at a time.

Type an invalid value, then leave the field. The left column uses :invalid (red from the start), the right :user-invalid:

<style>
  .cols { display: flex; gap: 16px; flex-wrap: wrap; }
  label { display: grid; gap: 4px; }
  input { font: inherit; border: 2px solid var(--chip);
    border-radius: 4px; padding: 4px; }
  .now input:invalid,
  .user input:user-invalid {
    border-color: var(--graph-1); }
</style>
<div class="cols">
  <label class="now">Email (:invalid)
    <input type="email" required></label>
  <label class="user">Email (:user-invalid)
    <input type="email" required></label>
</div>

Two workable strategies:

1. Native: keep browser validation, style with :user-invalid, set title on pattern fields, write hints next to the fields. No JavaScript, rough UX.
2. Custom: novalidate on the form, then use the constraint API (checkValidity(), validity, setCustomValidity()) to show your own inline messages and an error summary. The markup stays the same; the script is in Forms (TypeScript).

Either way, validate again on the server: attributes are trivially bypassed.

File uploads

<form action="/upload" method="post"
  enctype="multipart/form-data">
  <label for="photos">Photos (JPEG or PNG, max 10 MB)</label>
  <input id="photos" name="photos" type="file"
    accept="image/jpeg,image/png" multiple required>
  <button>Upload</button>
</form>

Reading, previewing and uploading files with progress from script is in Forms (TypeScript).

Accessibility & UX rules

Common mistakes

Recipes

Login form

<form action="/login" method="post">
  <label for="username">Email</label>
  <input id="username" name="username" type="email"
    autocomplete="username webauthn" required
    spellcheck="false" autocapitalize="off">
 
  <label for="current-password">Password</label>
  <input id="current-password" name="password"
    type="password" autocomplete="current-password"
    required>
  <button type="button" aria-controls="current-password"
    aria-pressed="false">Show password</button>
 
  <button type="submit">Sign in</button>
  <a href="/forgot/">Forgot password?</a>
</form>

The toggle switches the field's type between password and text (and aria-pressed) in script. Keep ids stable; password managers use them as a signal. The webauthn token only does something once your script starts a conditional passkey request; without it the field behaves as a plain username field.

Sign-up with password rules

<form action="/signup" method="post">
  <label for="email">Email</label>
  <input id="email" name="email" type="email"
    autocomplete="email" required>
 
  <label for="new-password">Password</label>
  <input id="new-password" name="password"
    type="password" autocomplete="new-password"
    minlength="15" required
    aria-describedby="pw-hint pw-error">
  <p id="pw-hint">At least 15 characters. A passphrase
    of a few random words works well.</p>
  <p id="pw-error" hidden></p>
 
  <label>
    <input type="checkbox" name="news" value="yes">
    Send me product updates (optional)
  </label>
 
  <button type="submit">Create account</button>
</form>

Length beats composition rules: NIST SP 800-63B (revision 4, 2025) requires at least 15 characters for passwords used on their own (8 with multi-factor), forbids composition rules such as "one symbol, one capital", requires checking new passwords against a blocklist of common and breached values, and says verifiers should allow paste. Note that minlength counts UTF-16 code units, while NIST counts Unicode code points.

Address form

<fieldset>
  <legend>Delivery address</legend>
  <label for="a1">Address line 1</label>
  <input id="a1" name="line1" required
    autocomplete="shipping address-line1">
  <label for="a2">Address line 2 (optional)</label>
  <input id="a2" name="line2"
    autocomplete="shipping address-line2">
  <label for="town">Town or city</label>
  <input id="town" name="town" required
    autocomplete="shipping address-level2">
  <label for="county">County (optional)</label>
  <input id="county" name="county"
    autocomplete="shipping address-level1">
  <label for="pc">Postcode</label>
  <input id="pc" name="postcode" required size="8"
    autocomplete="shipping postal-code"
    autocapitalize="characters" spellcheck="false">
  <label for="ctry">Country</label>
  <select id="ctry" name="country" required
    autocomplete="shipping country">
    <option value="GB" selected>United Kingdom</option>
    <option value="IE">Ireland</option>
  </select>
</fieldset>

Don't validate postcode formats too strictly on the client; international formats vary, and a typeahead or lookup service is kinder than a rejected pattern.

Search form

<search>
  <form action="/search" method="get">
    <label for="q">Search the docs</label>
    <input id="q" name="q" type="search"
      enterkeyhint="search" autocomplete="off"
      spellcheck="false">
    <button type="submit">Search</button>
  </form>
</search>

method="get" makes results shareable and bookmarkable. autocomplete="off" is reasonable here: the browser's history of past queries is rarely useful in a site search.

Radio group in a fieldset

<fieldset>
  <legend>Delivery speed</legend>
  <label>
    <input type="radio" name="speed" value="std" checked>
    Standard, 3–5 days (free)
  </label>
  <label>
    <input type="radio" name="speed" value="next">
    Next day (£4.99)
  </label>
</fieldset>

Pre-select the most common safe option; a required radio group with nothing checked forces an extra click and an error.

One-time code

<label for="otp">Verification code</label>
<input id="otp" name="otp" type="text"
  inputmode="numeric" autocomplete="one-time-code"
  pattern="\d{6}" maxlength="6" required
  aria-describedby="otp-hint">
<p id="otp-hint">6 digits, sent to your phone.</p>

One field, not six boxes: paste and autofill just work. End the SMS with the origin-bound line @acme.example #123456 so Safari's autofill and Chrome's WebOTP API only offer the code on your domain.

References

• MDN: <form> (opens in a new tab) and <input> (opens in a new tab): attributes and every input type
• MDN: pattern (opens in a new tab): anchoring and the v flag
• MDN: autocomplete (opens in a new tab): the full token list, sections and webauthn
• MDN: <button> (opens in a new tab), <select> (opens in a new tab), <textarea> (opens in a new tab), <meter> (opens in a new tab): element references
• MDN: Customizable select elements (opens in a new tab): appearance: base-select step by step
• MDN: :user-invalid (opens in a new tab): when it starts matching
• WHATWG HTML: Forms (opens in a new tab) and Form submission (opens in a new tab): implicit submission and the entry list
• WebKit: Features for Safari 27.0 (opens in a new tab): customizable select shipping in Safari
• Chrome for Developers: The select element can now be customized with CSS (opens in a new tab): the Chrome 135 launch
• web.dev: Sign-in form best practices (opens in a new tab) and Sign-up form best practices (opens in a new tab): autocomplete, ids and password fields
• web.dev: SMS OTP form best practices (opens in a new tab): the one-time-code field and SMS format
• GOV.UK: Why we changed the input type for numbers (opens in a new tab): Hanna Laakso on type="number" (2020)
• GOV.UK Design System: Date input (opens in a new tab) and Error summary (opens in a new tab): tested patterns
• WAI: Forms tutorial (opens in a new tab): labels, grouping, instructions and notifications
• WCAG 2.2 (opens in a new tab): 1.3.5, 2.5.3, 2.5.8, 3.3.1–3.3.3, 3.3.7, 3.3.8
• NIST SP 800-63B (opens in a new tab): password length and composition guidance
• Web Platform Status (opens in a new tab): Baseline data for input types, :user-invalid, field-sizing and customizable select