30 Tailwind CSS Login Forms

The eye control in the password field is a real <button> with aria-pressed, but the actual reveal needs a few lines of JavaScript — Tailwind can style both states yet cannot rewrite an input's type. On click you flip aria-pressed between true and false and swap the field from type=password to type=text. Keep the button inside the field with relative on the wrapper and absolute on the button so revealing never shifts the layout. The common trap is placing the toggle after the submit button in the tab order — put it right after the input so keyboard users reach reveal before submit, and give it an aria-label like Show password, because the icon alone tells a screen reader nothing.

The sliding Login / Sign Up panel, the 3D flip card and the slide-over all run on a hidden checkbox plus Tailwind peer variants — zero JavaScript. You place a focusable <input> of type checkbox before the animated element, mark it peer, then drive the transform with utilities like peer-checked:translate-x-full or a peer-checked:[transform:rotateY(180deg)] arbitrary value. A <label> tied to the checkbox id becomes the toggle button. The catch that breaks most attempts: peer only reaches later siblings, so the checkbox must physically precede the panel in the DOM — a checkbox nested inside the card cannot style its own ancestor. Keep the checkbox reachable, not display-none, so Space still toggles it for keyboard users.

Floating labels use the peer pattern with placeholder-shown: the label rests over the field, then peer-focus and peer-[:not(:placeholder-shown)] lift and shrink it. If it never moves, three things usually explain it. First, the input needs a real placeholder value — even a single space — or placeholder-shown can never switch off. Second, the label must come after the input in markup, and peer must sit on the input, because a label before the input gets no peer signal. Third, colour the placeholder text transparent so the placeholder string does not bleed through under the resting label. Once those line up the whole transition is pure Tailwind — no state library and no keystroke handler involved.

The six-box OTP grid and the numeric PIN pad both need JavaScript — Tailwind handles the layout, gaps and focus rings, but auto-advance is behaviour, not style. Each digit is its own input with inputmode=numeric and maxlength=1; on input you move focus to the next box, and on Backspace in an empty box you move back. Add a paste listener on the first field so a full pasted code fans out across all six boxes instead of dumping into one — that is the detail people forget. Give the group an accessible label, keep each box a real input, and set autocomplete=one-time-code so SMS autofill and password managers still fire. Do not collapse the six inputs into one masked field; you lose per-digit focus and the auto-advance entirely.

Every form pairs a real <label> to each input through for and id, so do not strip those for placeholder-only fields — a placeholder disappears on focus and is invisible to screen readers. Icon-only controls (the password eye, the biometric glyph, the social buttons) each carry an aria-label. The password toggle exposes its state via aria-pressed, and the inline-validation demos lean on the native :user-valid and :user-invalid pseudo-classes so an error only announces after the user has actually interacted with the field. Keep the focus ring visible — several demos use focus-visible:ring — and never signal valid or invalid with colour alone; pair the red border with a text hint so colour-blind users receive the same message.

Skip the flashier demos when the context fights them. The glassmorphism card's backdrop-filter blur is cheap on modern GPUs but stutters on old Android and is unsupported in a few embedded webviews, so ship a solid-colour fallback. The animated conic-gradient border and the drifting aurora blobs run continuous animation — gate them behind motion-reduce:animate-none for anyone who has requested reduced motion. The particle-constellation login redraws a <canvas> every frame; it is the one demo here that is not pure markup, and it is the wrong pick for a low-power kiosk or a page that must stay lightweight. For high-friction banking or B2B sign-in, the split-screen or secure-vault card earns trust far better than a neon arcade skin.

The meter is four segment bars plus a word label driven by a data-score attribute — Tailwind paints each score with variants like data-[score=3]:bg-emerald-500, but a small script has to set that attribute. On each keystroke you estimate strength (length, mix of character classes, a common-password check) into a 0-to-4 score and write it onto the wrapper's data-score; the CSS then lights the right number of segments from red to green. Do not treat this as real security — it is a UX hint, and the server must still enforce policy. For accessibility, render the word label (Weak / Strong) as text with aria-live=polite so the estimate is announced as it updates, rather than conveying strength through bar colour alone.

Most are pure Tailwind: the split-screen, gradient-border, neo-brutalist and glassmorphism cards are markup and utility classes only, and the sliding-panel, 3D-flip and slide-over demos stay script-free by driving state through a hidden checkbox and peer-checked variants. The ones that genuinely need JavaScript are the behavioural inputs — OTP auto-advance, the PIN pad, the show/hide password toggle, the live strength meter, the mascot that tracks the email field, and the canvas particle field. A quick rule: if the interaction only looks different — a transform, a colour, a reveal — Tailwind's state variants handle it; if it has to compute a value or move focus, you need a handler. Each of those demos ships its own self-contained script in the JS panel to copy.