HTML Forms — Inputs & Validation Basics
form, every common input type, labels, placeholder, and the built-in validation attributes browsers already give you for free.
Everything a Form Needs to Actually Submit
A <form> element wraps every input that should be submitted together, and its two most important attributes decide where and how that submission happens: action (the URL the data is sent to) and method (usually GET or POST).
<form action="/submit-signup" method="POST">
<input type="text" name="email">
<button type="submit">Sign up</button>
</form>Without a name attribute on an input, its value is simply never included in the submitted data at all — this is one of the single most common reasons a "working" form silently submits incomplete data, covered in depth in the Common Mistakes section below.
Every Common Input Type, With Real Behavioural Differences
The type attribute on <input> is not cosmetic — each type changes the keyboard shown on mobile, the built-in validation applied, and sometimes the entire UI the browser renders.
<input type="text"> <!-- plain single-line text -->
<input type="email"> <!-- validates a basic email SHAPE, shows an email keyboard on mobile -->
<input type="password"> <!-- masks characters as they're typed -->
<input type="number"> <!-- spinner arrows, numeric keyboard, rejects non-numeric text entry -->
<input type="tel"> <!-- numeric-leaning keyboard on mobile, NO format validation at all -->
<input type="url"> <!-- validates a basic URL shape -->
<input type="date"> <!-- a native date picker widget -->
<input type="checkbox"> <!-- boolean toggle -->
<input type="radio"> <!-- one choice from a group (Part 07 of the next module covers grouping) -->
<input type="hidden"> <!-- submitted with the form, never shown or editable by the user -->02139 becomes 2139), and its spinner arrows are frequently unwanted UI. For anything that looks like a number but is really an identifier — ZIP codes, phone numbers, credit card numbers — type="text" with a pattern attribute (Part 05) is usually the better, more correct choice.Not Decorative — a Real Programmatic Connection
A <label> is not just text sitting near an input — its for attribute, matched against the input's id, creates a genuine programmatic association that screen readers depend on and that expands the input's clickable area for every user.
<label for="email-address">Email address</label>
<input type="email" id="email-address" name="email">
<!-- Clicking the WORD "Email address" now focuses the input — try it in a real browser --><label>
Email address
<input type="email" name="email">
</label>
<!-- No "for"/"id" pairing needed — the wrapping relationship IS the association -->Both forms are valid and equally accessible. The explicit for/id form is generally preferred in real codebases because it doesn't constrain the input's position in the DOM relative to its label, making more layout options possible.
placeholder is not a label — a genuinely common, genuinely serious mistake
<input type="email" name="email" placeholder="Email address">
<!-- Looks fine visually. Has NO accessible name. A screen reader announces "edit text, blank". --><label>; use placeholder only for a genuine example of the expected format, never as a replacement for the label itself.The Browser Blocks Submission Before Your Code Ever Runs
<input type="email" name="email" required>
<input type="number" name="age" min="13" max="120">
<input type="password" name="password" minlength="8" maxlength="64" required>These constraint attributes are checked entirely by the browser, before any form submission is even attempted — if required is present and the field is empty, the browser blocks submission and shows its own native validation message, with zero JavaScript written.
Custom Validation Rules With Regular Expressions
<input type="text" name="zip" pattern="[0-9]{5}" title="A 5-digit ZIP code" required>
<input type="text" name="phone"
pattern="[0-9]{3}-[0-9]{3}-[0-9]{4}"
title="Format: 123-456-7890"
placeholder="123-456-7890">The title attribute here is not a tooltip decoration — many browsers surface it directly inside the native validation error message ("Please match the requested format:" + the title text), so it should describe the expected format in plain language, not restate the regex.
Styling Based on Validation State, With No JavaScript
input:invalid {
border-color: #ff4757;
}
input:valid {
border-color: #00e676;
}
/* An empty required field is :invalid the instant the page loads — this
often means every required field shows red before the user has typed
anything at all, which usually reads as broken rather than helpful */
input:placeholder-shown:invalid {
border-color: initial; /* suppress the red state until the user actually interacts */
}These pseudo-classes update live as the user types, reflecting exactly what the browser's own constraint validation (required/pattern/min/max) currently thinks of the field — no JavaScript event listener required to keep the styling in sync.
A Signup Form Silently Dropping Fields, at a Denver SaaS Startup
A newly redesigned signup form visually looks identical to the old one — same fields, same layout. Support starts getting tickets from users saying their company name never shows up anywhere after signing up, even though they clearly typed it in.
<label>Company name</label>
<input type="text" id="company" placeholder="Acme Inc.">
<!-- no "name" attribute on the input at all -->What actually happened
The designer who rebuilt the form's markup copied the visual structure carefully but dropped the name attribute on several inputs during the rewrite — without it, the browser simply never includes that field in the submitted form data at all, no error, no warning, nothing visibly different in the UI. The field renders, accepts input, looks completely normal, and is silently absent from every single submission. The team's own retrospective: "the browser did exactly what we told it — we just told it to submit a form with an unnamed field, which means submit nothing for that field at all."
Four Misconceptions About HTML Forms
5 Interview Questions — With Complete Answers
Form Mistakes Beginners Make Constantly
Issues You Will Hit With Forms — And Exactly Why
🎯 Key Takeaways
- ✓The name attribute is what makes an input's value get included in a form submission — omit it and the field is silently dropped, with no error shown anywhere.
- ✓Input types are not cosmetic — they change the mobile keyboard, the native UI, and the built-in validation applied. type="number" is often the wrong choice for number-shaped identifiers like ZIP codes.
- ✓A <label> creates a real programmatic association (via for/id or implicit wrapping) that expands the clickable area and is essential for screen readers — placeholder text is never a substitute.
- ✓required/pattern/min/max are checked entirely by the browser before submission, with zero JavaScript — but they are bypassable via a direct request, so server-side validation remains mandatory.
- ✓The title attribute on a pattern-constrained input often appears directly inside the browser's native validation error message, so write it as a plain-language format description.
- ✓:valid/:invalid pseudo-classes let you style based on the browser's live constraint-validation state with no JavaScript event listeners required.
What comes next
Module 09 goes further into forms — select, textarea, fieldset, radio and checkbox groups, and the details of how a form actually submits.
Module 09 → HTML Forms — AdvancedDiscussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.