Form Validation

HTML5 gives browsers built-in, JavaScript-free form validation — required, pattern, min/max, and correct input types all combine to block bad submissions before they even leave the browser.

Syntax

<input type="email" required>
<input type="text" pattern="[A-Za-z]{3,}" required>
<input type="number" min="1" max="10">

Basic Example

<form>
    <label for="email">Email</label>
    <input type="email" id="email" name="email" required>
    <button type="submit">Submit</button>
</form>

Browser output: attempting to submit with an empty or invalid email shows a native popup ("Please fill out this field" or "Please include an '@' in the email address") pointing directly at the offending field — no custom code required.

How It Works

1. The browser checks every field's constraints (required, type-based format, pattern, min/max) the moment the form is submitted.
2. If anything fails, submission is blocked entirely, and the browser focuses and highlights the first invalid field with a native message.
3. CSS :valid and :invalid pseudo-classes let you style fields based on their current validation state.

Important Attributes

Real-World Example

<style>
    input:invalid { border-color: #DC2626; }
    input:valid { border-color: #16A34A; }
</style>
<input type="email" required>

Styling a field's border color based purely on its live validation state — red while invalid, green once it passes — all using native CSS pseudo-classes, no JavaScript needed.

Common Mistakes

• Treating HTML5 client-side validation as a substitute for server-side validation — client-side checks can always be bypassed (disabled JavaScript, direct API calls, browser dev tools), so the server must always re-validate independently
• Using novalidate to disable native validation without replacing it with an equally robust custom validation system

Best Practices

• Use native HTML5 validation as the first, fast, user-friendly layer
• Always re-validate everything server-side too — this is a genuine security requirement, not just good practice

Accessibility Considerations

Native validation messages are announced by screen readers and are keyboard-navigable by default — a real advantage over many custom JavaScript validation UIs, which often require significant extra work to reach the same accessibility baseline.

SEO Considerations

No direct ranking effect, though a well-validated, low-friction form directly improves real conversion outcomes.

Browser & Modern HTML Notes

Native validation message wording and styling vary by browser and can't be fully customized with CSS alone — the JavaScript Constraint Validation API exists for cases needing fully custom validation messages and UI.

Mini Practice

1. Build a form with required, pattern, and min/max constraints combined, and test the native error messages.
2. Style a field using CSS :invalid and :valid.

Related HTML Notes

• required
• pattern
• min-max