The Best Examples of Tailwind Forms for Modern Websites

Most form tutorials show you what’s possible. This one shows you what actually works.

The State of CSS 2024 survey puts Tailwind CSS at 62% developer usage. More teams are building their form UI with utility classes now than ever before, and the patterns they use vary a lot.

This guide covers the most useful examples of Tailwind forms you’ll actually build: login forms, contact forms, registration layouts, multi-step flows, inline inputs, dark mode styling, validation states, and accessibility requirements.

By the end, you’ll have working markup for each pattern plus a clear understanding of which component libraries save the most time.

What Is a Tailwind Form

A Tailwind form is an HTML form styled entirely with Tailwind CSS utility classes, with no custom CSS written separately. Every visual property, from input border radius to focus ring color, is applied directly in the markup using single-purpose utility classes like px-4, border, rounded-md, and text-sm.

This is a different way of thinking about form design. Instead of inventing class names like .contact-form__input and writing matching CSS in a separate file, you compose the entire visual layer inside the HTML element itself.

How Tailwind differs from traditional CSS form styling

Traditional CSS forms rely on authored class names and a linked stylesheet. Tailwind eliminates both. You never leave the HTML file to change a color or adjust spacing.

The State of CSS 2024 survey puts Tailwind at 62% developer usage with 81% satisfaction, compared to Bootstrap at 28% usage and 55% satisfaction. That satisfaction gap shows up clearly in how teams approach form UI work.

OpenAI, Shopify, Vercel, and Cloudflare all use Tailwind in production. The framework’s JIT compilation ships only the utility classes actually used, which is why production CSS bundles stay small even on complex form pages.

What “utility-first” means for form input styling

One class, one property. That is the whole idea. border-gray-300 sets one border color. rounded-md sets one border-radius. focus:ring-2 applies a focus ring only on focus state.

This makes form field spacing and visual hierarchy easy to adjust without touching a stylesheet. It also means two developers working on the same form can both understand the styling at a glance, which is not always true with authored CSS.

What Does the @tailwindcss/forms Plugin Do

The @tailwindcss/forms plugin is a form reset layer maintained by Tailwind Labs. It strips inconsistent browser defaults from form elements and replaces them with a clean, utility-friendly baseline so standard Tailwind classes can override everything predictably.

Without it, elements like <select>, <input type="checkbox">, and <textarea> render differently across Chrome, Firefox, Safari, and Edge. The plugin fixes that by applying appearance: none and a normalized set of base styles across all major form controls.

What the plugin resets and what it does not touch

Controls the plugin normalizes:

• Text inputs (type="text", email, password", url, search)
• Textarea elements
• Select and multi-select dropdowns
• Checkboxes and radio buttons
• File inputs

The plugin does not add design. It only removes the inconsistency so you can apply Tailwind utility classes reliably. Think of it as clearing a whiteboard, not drawing on it.

How to install and configure the plugin

Install via npm: npm install @tailwindcss/forms

For Tailwind CSS v4, add this to your main stylesheet:

@import "tailwindcss";
@plugin "@tailwindcss/forms";

For Tailwind CSS v3, register it in tailwind.config.js:

plugins: [require('@tailwindcss/forms')]

The plugin offers 2 strategy modes. Use base for a global reset across all form elements in the project. Use class to opt in per element, which avoids conflicts when integrating Tailwind into an existing design system.

Why cross-browser form consistency matters

Zuko Analytics data shows 55% of users who visit a form abandon it without completing. Visual inconsistency across browsers adds friction that contributes to that drop-off, particularly on select dropdowns and checkboxes where default browser styling is hardest to override without a reset layer.

The plugin makes that problem disappear with a single install. It is one of the highest-leverage setup steps when building any Tailwind CSS form UI.

What Are the Most Common Tailwind Form Examples

The 5 form input types developers style most often in Tailwind are text inputs, textareas, select dropdowns, checkboxes and radio buttons, and file inputs. Each has a distinct set of utility classes that handles its specific styling challenges.

Text Input Example

Text inputs are the starting point for almost every form UI. The core pattern uses a small, consistent set of Tailwind utility classes that covers layout, border, color, and focus state.

See the Pen
Tailwind CSS Text Input Component Library by Bogdan Sandu (@bogdansandu)
on CodePen.

Key utilities explained:

• w-full: makes the input fill its container width
• px-4 py-2: horizontal and vertical padding
• border border-gray-300: visible border with muted color
• rounded-md: slightly rounded corners
• focus:ring-2 focus:ring-blue-500: visible focus ring for keyboard users
• placeholder:text-gray-400: styled placeholder text (Tailwind v3+)

Never remove focus:outline-none without replacing it with a visible focus:ring. Removing the outline entirely breaks keyboard navigation and fails WCAG 2.2 focus-visible requirements.

Textarea Example

Textareas share the same base utility pattern as text inputs. The one addition is resize control.

See the Pen
Textarea Components – Tailwind CSS by Bogdan Sandu (@bogdansandu)
on CodePen.

Use resize-y to allow vertical resize only. Use resize-none to lock the size entirely, which makes sense inside constrained layouts. Avoid resize (both directions) unless the design can accommodate horizontal stretching.

Select Dropdown Example

Select elements require the @tailwindcss/forms plugin to be overrideable with utility classes. Without the reset, appearance: none must be added manually, and even then browser rendering stays inconsistent.

See the Pen
Select Dropdown Examples – Tailwind CSS by Bogdan Sandu (@bogdansandu)
on CodePen.

WPForms data shows forms with radio buttons are completed 2.5 seconds faster on average than forms with dropdown selects. Use a select only when the option list exceeds 5–6 items. Below that, radio buttons usually convert better and are easier to style in Tailwind.

Checkbox and Radio Button Example

See the Pen
Accessible Form Controls – Checkboxes, Radios & Toggles by Bogdan Sandu (@bogdansandu)
on CodePen.

Always use <fieldset> and <legend> for radio groups. Screen readers announce the group context from <legend> before reading each option. Skipping this is one of the most common form accessibility mistakes.

File Input Example

File inputs have two styling surfaces: the input wrapper and the internal button. Tailwind v3+ exposes the button via the file: pseudo-element variant.

See the Pen
File Inputs – Tailwind CSS Styling Reference by Bogdan Sandu (@bogdansandu)
on CodePen.

The file: variant targets the browser-native file button. file:mr-4 adds spacing between the button and the filename text. Without the @tailwindcss/forms plugin, the base file input styling is harder to normalize across browsers.

What Does a Tailwind Login Form Look Like

A Tailwind login form combines an email input, a password input, a “remember me” checkbox, and a submit button inside a centered card container. The full pattern relies on max-w-md, mx-auto, and shadow for the card layout, with consistent focus ring and border styling across all fields.

See the Pen
Modern Form Collection with Tailwind CSS by Bogdan Sandu (@bogdansandu)
on CodePen.

Key decisions in this login form pattern

Zuko Analytics data shows the password field has the highest drop-off rate of any form field at 10.5%. Adding autocomplete="current-password" lets password managers pre-fill the field, which directly reduces that friction.

Accessibility requirements met in this layout:

• Every input has a visible <label> with a matching for attribute
• Focus rings are visible and meet WCAG 2.2 focus-visible criteria
• autocomplete attributes are set on both fields
• Submit button is full-width and keyboard-accessible

GitHub uses a similar full-width card login pattern with consistent focus ring styling. The layout works because it keeps visual weight on a single task: entering credentials and submitting.

What Does a Tailwind Registration Form Look Like

A Tailwind registration form extends the login pattern with additional fields and a two-column grid layout on larger screens. The standard structure includes first name, last name, email, password, confirm password, and a terms checkbox, with fields stacking on mobile via grid-cols-1 sm:grid-cols-2.

See the Pen
Tailwind CSS Registration Forms by Bogdan Sandu (@bogdansandu)
on CodePen.

Error state and validation styling

The confirm password field above shows the error state pattern: border-red-500 on the input, text-red-600 on the helper text below it. This is a CSS-only approach that works with any JS validation library.

Baymard Institute 2024 data shows the average checkout form has 11.3 visible fields even though only ~8 are required, and 18% of users abandon because forms feel too long. Registration forms face the same problem. Reducing the initial field count and using a two-column grid for name fields shortens perceived length without removing required data.

See more registration form examples for layout and field structure variations across different use cases.

What Does a Tailwind Contact Form Look Like

A Tailwind contact form typically combines 4 fields: name, email, subject, and message. The layout uses space-y-4 on the form container for consistent vertical spacing between fields, with a full-width textarea for the message.

See the Pen
Tailwind CSS Contact Form Examples by Bogdan Sandu (@bogdansandu)
on CodePen.

Contact form layout decisions

The space-y-4 utility on the <form> element is a cleaner alternative to adding mb-4 to every field div. It applies consistent top-margin between all direct children, which makes adding or removing fields later easier.

resize-none on the textarea is a deliberate choice here. Inside a fixed-width card, letting users drag the textarea wider breaks the layout. Use resize-y if the design has enough room to absorb vertical growth.

The Zuko Analytics data point on email field abandonment (6.4% drop-off rate) is worth noting for contact forms. The email field is the second-highest abandonment point after password. Pre-filling it via browser autofill reduces friction. Adding autocomplete="email" to the input handles that.

For real-world design reference, check these contact form examples showing how different industries handle field order, placeholder text, and submit button copy.

What Does a Tailwind Search Form Look Like

A Tailwind search form pairs a text input and a submit button side by side using a flex container. The input takes remaining space with flex-1 and the button stays fixed-width with shrink-0. The layout is used in site headers, filter bars, and product search interfaces.

See the Pen
Tailwind CSS Search Bar Examples by Bogdan Sandu (@bogdansandu)
on CodePen.

Responsive and mobile behavior

For full-width mobile layouts, wrap the form in a w-full container and let the flex layout handle proportional sizing naturally. The input already uses flex-1 min-w-0, so it shrinks correctly on small screens without any breakpoint overrides needed.

The min-w-0 class matters here. Without it, flex items can overflow their container on narrow viewports because the browser respects the intrinsic minimum width of the input. Adding min-w-0 removes that constraint and lets the input shrink below its default size.

For a search bar embedded in a navigation header, add flex-col sm:flex-row to stack the input and button vertically on mobile and inline on larger screens.

The sr-only label above is not optional. Screen readers need a programmatic label on the input. The placeholder attribute is not a label substitute and does not satisfy WCAG 1.3.1.

What Does a Tailwind Multi-Step Form Look Like

See the Pen
Multi-Step Form with Alpine.js + Tailwind CSS by Bogdan Sandu (@bogdansandu)
on CodePen.

HubSpot data shows multi-step forms convert 86% higher than single-step alternatives for forms collecting 7 or more fields. The Tailwind multi-step pattern splits those fields across sequentially revealed steps, each managed by JavaScript state or Alpine.js directives.

How step validation works in this pattern

The validateStep() function runs on every “Next” click before advancing. It checks only the fields visible in the current step, not the entire form, which prevents users from getting blocked by errors they haven’t reached yet.

Error state classes are applied conditionally:

• :class="errors.name ? 'border-red-500' : 'border-gray-300'" on the input
• x-show="errors.name" on the helper text element below

Empire Flippers added a progress bar and clickable step buttons to their multi-step business valuation form and saw a 51.6% conversion increase in 47 days, which shows how much the visual progress signal matters.

See more multi-step form examples across different layouts and use cases for further reference.

What Does a Tailwind Inline Form Look Like

An inline form pairs an input and a button side by side using flex items-center gap-2. The input takes remaining space with flex-1 min-w-0 and the button stays fixed-width with shrink-0. This layout is used for newsletter signups, coupon code entry, and email capture strips.

See the Pen
Inline Form Patterns with Tailwind CSS by Bogdan Sandu (@bogdansandu)
on CodePen.

Responsive stacking behavior

Mobile: flex-col stacks input and button vertically, both full-width.

Desktop: sm:flex-row switches to side-by-side layout at the sm breakpoint (640px+).

The min-w-0 on the input is not optional. Without it, flex items respect the browser’s intrinsic minimum input width, which causes overflow on narrow viewports. Adding min-w-0 removes that constraint.

Autofill support matters here too. Chrome DevTools research shows that when browser Autofill is enabled and fires, forms are completed 35% faster with 75% lower abandonment. Setting autocomplete="email" directly enables that.

What Does a Tailwind Dark Mode Form Look Like

As of 2024, 81.9% of smartphone users use dark mode on their devices (Almax Agency). Forms that don’t adapt to dark mode create immediate visual friction for the majority of mobile users.

Tailwind handles dark mode forms through the dark: variant, which applies styles only when the dark class is present on the <html> element (class strategy) or when the OS prefers dark (media strategy).

See the Pen
Dark Mode Forms – Tailwind CSS Patterns & WCAG Contrast Reference by Bogdan Sandu (@bogdansandu)
on CodePen.

Enabling dark mode in Tailwind config

Class strategy (recommended for user-toggled dark mode):

// tailwind.config.js
module.exports = {
darkMode: 'class',
// ...
}

Toggle dark mode by adding or removing the dark class on <html> via JavaScript. This is the standard pattern used by Vercel’s dashboard and Linear’s UI.

Media strategy (follows OS preference automatically):

darkMode: 'media'

No JavaScript required. The form adapts to prefers-color-scheme: dark without a toggle. Tailwind v4 uses this as the default.

WCAG contrast requirements in dark mode

Dark mode is not just inverted colors. WCAG 2.1 AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text, verified independently for both light and dark themes.

text-gray-900 dark:text-white passes. text-gray-400 dark:text-gray-600 often fails. Every dark palette combination needs a separate contrast check, not just an inversion of the light theme values.

How Do Tailwind Form Validation States Work

Tailwind supports 2 approaches to form validation styling: native HTML5 pseudo-class utilities using the peer pattern, and custom JavaScript-driven class toggling. Both use the same visual output: border-red-500 for errors, border-green-500 for valid states, and helper text below the field.

Native validation styling with peer utilities

The peer utility is applied to the input element. A sibling element then uses peer-invalid or peer-valid to conditionally show or hide based on the input’s validation state.

See the Pen
Tailwind CSS Form Validation with Inline Error States by Bogdan Sandu (@bogdansandu)
on CodePen.

One catch: The invalid: pseudo-class fires immediately on page load for required fields before the user has typed anything. Add focus:invalid:border-red-500 instead of invalid:border-red-500 to delay the error styling until after the user has interacted with the field.

See detailed guidance on form validation best practices covering when to trigger errors, inline vs. summary patterns, and accessibility requirements.

Custom JavaScript validation states

JS-driven validation gives more control over when errors appear and how they are cleared. The pattern toggles classes on the input element and shows or hides the error element based on a validation function result.

<!-- JS validation pattern (Alpine.js) -->
<div
x-data="{
email: '',
touched: false,
get isValid() { return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(this.email); },
get showError() { return this.touched && !this.isValid; }
}"
class="mb-4"
>
<label for="js-email" class="block text-sm font-medium text-gray-700 mb-1">
Email address
</label>
<input
type="email"
id="js-email"
x-model="email"
@blur="touched = true"
:class="showError
? 'border-red-500 focus:ring-red-500'
: 'border-gray-300 focus:ring-blue-500'"
class="w-full px-4 py-2 border rounded-md text-gray-900 placeholder:text-gray-400
focus:outline-none focus:ring-2"
placeholder="[email protected]"
:aria-invalid="showError"
:aria-describedby="showError ? 'email-error' : null"
/>
<p
id="email-error"
x-show="showError"
class="mt-1 text-sm text-red-600"
role="alert"
>
Please enter a valid email address.
</p>
</div>

The @blur event sets touched = true only after the user leaves the field. This prevents the red border from showing immediately when the form loads.

Accessibility attributes used here:

• :aria-invalid="showError" tells screen readers the field has an error
• :aria-describedby links the input to the error message by ID
• role="alert" on the error element announces the message to screen readers when it appears

How Does Tailwind Form Accessibility Work

The first half of 2025 saw 2,014 ADA website lawsuits, a 37% increase from 2024 (EcomBack). Forms are a primary target because label, focus, and ARIA failures are easy to detect programmatically. The good news is that Tailwind makes it straightforward to build accessible forms if you know which patterns to use.

Label and focus ring requirements

Every input needs a visible label. Not a placeholder. A <label> element with a for attribute matching the input’s id.

Placeholders disappear on input and fail WCAG 1.3.1. They work as hints, not labels. Never use them as the only way to identify a field.

For designs where a visible label breaks the layout, use Tailwind’s sr-only class to keep the label accessible to screen readers without showing it visually:

<label for="hidden-label-input" class="sr-only">Search</label>
<input type="search" id="hidden-label-input" ... />

Focus ring: Never remove focus:outline-none without replacing it. The correct replacement is focus:ring-2 focus:ring-blue-500. WCAG 2.2 requires focus indicators to be visible. The WebAIM Million 2025 report shows 94.8% of websites still fail basic WCAG checks. Focus visibility is one of the top failure types.

ARIA attributes for forms

Tailwind does not generate ARIA attributes. Those are your responsibility, applied directly in the HTML.

Keyboard navigation follows DOM order. Avoid using tabindex with positive values. Positive tabindex values break the natural tab sequence and make forms harder to use with a keyboard.

Radio button groups need <fieldset> and <legend>. Without them, screen readers read each radio option without the group context, so users cannot understand what they are choosing between. This is one of the most commonly missed HTML form requirements.

What Are the Best Tailwind Form Component Libraries

DaisyUI leads in raw adoption with 19 million+ npm installs (DesignRevision). Beyond DaisyUI, 4 other libraries cover specific use cases well: Flowbite for polished production components, Headless UI for accessible unstyled primitives, Preline UI for HTML-first teams, and Tailwind UI for teams that want the official Tailwind Labs component set.

Flowbite

Flowbite provides 600+ components designed in Figma with matching Tailwind markup. Form components include text inputs, selects, file uploads, multi-step forms, and floating label variants.

Supports React, Vue, Svelte, and plain HTML. All components include dark mode variants out of the box. Good pick when you need polished form UI without spending time on base styling work.

Headless UI

Built and maintained by Tailwind Labs. Zero styling included. You supply every Tailwind class. Headless UI handles the hard parts: keyboard navigation, ARIA roles, focus trapping, and screen reader announcements.

Form-relevant components: Listbox (accessible custom select), Combobox (searchable select with autocomplete), Switch (toggle), RadioGroup.

Best pick when you need total visual control but cannot afford to write your own ARIA logic for complex interactive form elements. Not right if you want something visually finished without styling work.

daisyUI

Adds semantic class names like input, select, checkbox, and form-control as a Tailwind plugin. Reduces markup verbosity significantly compared to raw Tailwind utility classes.

The validator component (added in recent versions) changes input colors to error or success states based on native HTML5 validation rules with no JavaScript required. Good for prototyping different types of forms quickly without writing utility class strings from scratch.

Preline UI

Free collection of copy-paste Tailwind components that work with plain HTML and Alpine.js. No installation or npm package required. Over 30 form components including floating label inputs, multi-step forms, and file upload zones.

Good for HTML-first projects where adding a JavaScript framework is not an option.

Tailwind UI

The official paid library from Tailwind Labs. Every form component is production-ready, responsive, accessible, and comes in React, Vue, and plain HTML variants. Form layouts include sign-in pages, registration flows, checkout forms, and settings panels.

Worth the cost for teams that ship frequently and need components that are already correct, not just functional. Vercel uses Tailwind UI components as a base for several internal dashboard forms.

FAQ on Tailwind Forms

Do I need the @tailwindcss/forms plugin to style forms?

No, but it helps significantly. Without it, elements like <select>, checkboxes, and radio buttons render inconsistently across Chrome, Firefox, and Safari. The plugin applies a clean baseline reset so standard Tailwind utility classes override everything predictably.

What is the best way to style a text input in Tailwind CSS?

Use w-full px-4 py-2 border border-gray-300 rounded-md as your base. Add focus:outline-none focus:ring-2 focus:ring-blue-500 for the focus ring. Always pair every input with a visible <label> element linked via matching for and id attributes.

How do I handle form validation states in Tailwind?

Two options: the native peer utility pattern using peer-invalid:block on a sibling error element, or JavaScript-driven class toggling with border-red-500 and text-red-600. The JS approach gives more control over when errors appear after user interaction.

How do I build a multi-step form with Tailwind CSS?

Use Alpine.js with x-show to conditionally render each step. Track the current step in x-data. Add a progress bar using an inline width percentage. Validate fields per step before advancing with a validateStep() function on each “Next” click.

How does dark mode work in Tailwind forms?

Set darkMode: 'class' in tailwind.config.js, then apply dark: variants directly on form elements. Use dark:bg-gray-800 on inputs, dark:text-white on labels, and dark:border-gray-600 on borders. Verify contrast ratios independently for both themes against WCAG 2.1 AA requirements.

What Tailwind utilities handle responsive form layouts?

For two-column layouts, use grid grid-cols-1 sm:grid-cols-2 gap-4. For inline forms, use flex flex-col sm:flex-row gap-2 so fields stack on mobile and sit side by side on larger screens. The min-w-0 class prevents input overflow on narrow viewports.

What are the best Tailwind CSS form component libraries?

Flowbite offers 600+ production-ready components. Headless UI (by Tailwind Labs) provides accessible unstyled primitives for custom selects and toggles. daisyUI adds semantic class names like input and form-control. Preline UI works without any JavaScript framework. Tailwind UI is the official paid option.

How do I make Tailwind forms accessible?

Every input needs a <label> with a matching for attribute. Never remove focus:outline-none without replacing it with a visible focus:ring. Add aria-invalid, aria-describedby, and role="alert" on error messages. Use <fieldset> and <legend> for radio button groups.

How do I style a select dropdown in Tailwind CSS?

Install @tailwindcss/forms first. The plugin resets appearance: none on the select element so utility classes apply reliably across browsers. Then style with w-full px-4 py-2 border border-gray-300 rounded-md bg-white plus standard focus ring utilities.

Can I use Tailwind forms with React or Next.js?

Yes. Tailwind utility classes work identically in JSX. For complex form state, pair Tailwind styling with React Hook Form or Formik for validation logic. shadcn/ui provides copy-paste React form components built on Radix UI primitives with full Tailwind styling and Zod schema validation support.

Conclusion

This conclusion is for an article presenting the full range of Tailwind CSS form patterns, from basic text input styling to multi-step flows with Alpine.js validation.

The @tailwindcss/forms plugin is where every project should start. It removes cross-browser inconsistency from select dropdowns, checkboxes, and file inputs before you write a single utility class.

Dark mode support, focus ring visibility, and ARIA attributes are not optional extras. They are the difference between a form that works for everyone and one that fails WCAG 2.1 AA compliance.

For component libraries, Flowbite, Headless UI, and daisyUI each solve a different problem. Pick based on your stack, not popularity.

Build the pattern that fits your use case. Then ship it.