Tailwind Form Validation Styling

What Does Form Validation Styling Involve?

Validation styling communicates a field's status, valid, invalid, or required, through color, icons, and text, ideally driven by both native HTML validation attributes and matching CSS pseudo-class variants.

Tailwind includes invalid: and required: variants that hook directly into the browser's native :invalid and :required pseudo-classes, letting you style validation states without extra JavaScript for many common cases.

<input
  type="email"
  required
  class="rounded-lg border border-slate-300 px-3 py-2 invalid:border-red-500 invalid:text-red-600 focus:outline-none focus:ring-1 focus:ring-blue-500"
/>

The browser's native email validation automatically triggers invalid: styling when the input doesn't contain a valid email address.

Validation Variant Syntax

class="invalid:border-red-500"
class="valid:border-emerald-500"
class="required:border-slate-400"
class="peer-invalid:block"

• invalid: applies styles when the input fails native HTML validation.
• valid: applies styles when the input successfully passes validation.
• required: applies styles to fields marked with the required attribute.
• peer-invalid: lets a sibling element (like an error message) react to an invalid input.

Form Validation Cheatsheet

Common validation state patterns and their triggers.

Styling Native HTML Validation

HTML attributes like required, type="email", minlength, and pattern trigger the browser's built-in validation engine. Tailwind's invalid:/valid: variants let you style the result directly, with zero JavaScript.

<input
  type="email"
  required
  class="rounded-lg border px-3 py-2 border-slate-300 valid:border-emerald-500 invalid:border-red-500"
/>

Note that empty required fields are often considered :invalid by default; many teams only show red styling after the user has interacted with the field, handled via JavaScript or the :user-invalid pseudo-class where supported.

Showing Error Messages With peer-invalid

Using the peer and peer-invalid: pattern, a sibling error message can automatically appear only when its associated input is currently invalid, without any JavaScript.

<div>
  <input type="email" required class="peer rounded-lg border border-slate-300 px-3 py-2 invalid:border-red-500" />
  <p class="mt-1 hidden text-sm text-red-600 peer-invalid:block">
    Please enter a valid email address.
  </p>
</div>

Styling JavaScript-Driven Validation

For validation logic handled in JavaScript (like matching password confirmation fields or async username availability checks), toggle an aria-invalid attribute and a matching class instead of relying on native :invalid, since custom validation rules aren't expressed through native HTML attributes.

<input
  id="username"
  aria-invalid="true"
  aria-describedby="username-error"
  class="rounded-lg border border-red-500 px-3 py-2 focus:ring-1 focus:ring-red-500"
/>
<p id="username-error" class="mt-1 text-sm text-red-600">This username is already taken.</p>

Accessible Validation Feedback

Validation errors must be announced to assistive technology, not just shown visually. Combine aria-invalid, aria-describedby, and visible text messages for every validation state.

• Always pair color-based error indicators with a visible text message.
• Use aria-describedby to programmatically connect an input with its error text.
• Consider announcing validation summaries with role="alert" for critical form-wide errors.

Common Mistakes

• Relying only on red border color to indicate an error, with no accompanying text message.
• Showing invalid: styling immediately on page load for empty required fields, before the user has had a chance to interact with them.
• Forgetting aria-invalid and aria-describedby on JavaScript-driven validation errors.
• Not testing native validation styling across different browsers, since :invalid behavior can vary slightly.
• Overloading forms with too many simultaneous validation messages instead of validating progressively as the user completes fields.

Key Takeaways

• Tailwind's invalid:/valid:/required: variants hook into native HTML validation pseudo-classes.
• peer-invalid: lets sibling error messages appear automatically based on an input's validity.
• JavaScript-driven validation should use aria-invalid and aria-describedby instead of relying on native pseudo-classes.
• Validation feedback must always include a visible text message, never color alone.
• Avoid showing error styling on untouched required fields immediately on page load.