Format an HTML Form with Validation

HTML5's built-in form validation attributes provide instant client-side feedback with zero JavaScript and no external library dependencies. Every modern browser implements required, type, pattern, minlength, maxlength, min, max, and step attributes for input elements, showing validation error messages in the browser's native style before the form is submitted. This makes forms immediately more user-friendly while reducing server load from obviously invalid submissions. This example shows a registration form with three fields demonstrating different validation approaches. The name field uses minlength="2" and maxlength="100" to enforce length bounds, plus placeholder to show expected format. The email field uses type="email" which triggers browser-native email format validation — the browser knows what a valid email structure looks like and rejects inputs without an @ symbol and domain. The password field combines type="password" (for masking) with minlength="8" and a pattern attribute containing a lookahead-based regex requiring at least one uppercase letter and one number. The novalidate attribute on the form element is an intentional addition to this example: it disables the browser's built-in validation so you can handle validation entirely with JavaScript and show custom error messages that match your application's design system rather than browser-native ones. Remove novalidate to re-enable native browser validation if you prefer its behavior. Label association is a critical accessibility requirement: every input must have an associated label element, connected either by the for attribute matching the input's id (as shown here) or by wrapping the input inside the label element. Screen readers announce the label text when the input receives focus. Without proper label association, screen reader users hear "text field, required" with no indication of what information is expected. The small element below the password field serves as help text that explains the pattern requirement before validation fails. Proactively communicating requirements reduces user frustration compared to showing an error message only after a failed submission attempt. Real-world scenarios: a quick registration form for a SaaS trial where native validation provides immediate feedback with no custom JavaScript; a checkout form where email validation prevents the most common typos before payment processing begins. Tips: always implement server-side validation even when you have client-side validation. Browser validation can be bypassed with browser developer tools or direct HTTP requests, so server-side checks are the only reliable security boundary.

<form method="post" action="/register" novalidate>
  <div>
    <label for="name">Full Name</label>
    <input type="text" id="name" name="name" required minlength="2" maxlength="100" placeholder="Jane Smith">
  </div>
  <div>
    <label for="email">Email</label>
    <input type="email" id="email" name="email" required autocomplete="email">
  </div>
  <div>
    <label for="password">Password</label>
    <input type="password" id="password" name="password" required minlength="8" pattern="(?=.*d)(?=.*[A-Z]).{8,}">
    <small>Min 8 characters, one uppercase, one number.</small>
  </div>
  <button type="submit">Create Account</button>
</form>