16 Tailwind CSS Floating Label Inputs

The mechanism is the peer class plus sibling state variants — no script runs at all. You mark the <input> as peer, then style the label with two variants: peer-placeholder-shown: (the resting state, label sitting inside the field) and peer-focus: (the floated state, label small and lifted). The trick that makes it purely CSS is giving the input a single-space placeholder, placeholder=" ". That keeps :placeholder-shown true only while the field is genuinely empty, so the label drops when there is a value and floats when the field is focused or filled. Demo 04 is the canonical form of this. Because everything is a state variant compiled to a real CSS selector, the label animates on focus, blur, autofill and back-button restore with zero runtime cost — the browser drives it entirely through the :placeholder-shown and :focus pseudo-classes.

This is the most common floating-label bug and it is not your CSS logic — it is timing. Chrome's autofill writes a value into the input without firing the events that change :placeholder-shown in the frame you expect, and the browser's own autofill styling repaints the field. Your label is still in its resting peer-placeholder-shown: position, so it crashes straight through the autofilled text. The fix is to add the autofill state as a second trigger for the floated position. Demo 05 does exactly this: it joins peer-autofill: to the same rules that peer-focus: already carries, so an autofilled field lifts the label just like a focused or typed-in one. Pair it with the usual peer-placeholder-shown: resting rule and the label now knows three ways to be "occupied": focused, filled by typing, or filled by autofill. Test it by saving a login and reloading — the label should already be floated on paint.

A floated label is still a real label — it must be programmatically bound, not just visually associated. Demo 07 wires it correctly: the <label> carries a for that matches the input's id, so clicking the label focuses the field and assistive tech announces the name. Hint and error text live in their own element referenced by aria-describedby, so the description is read after the label rather than being lost as decoration. Two things to watch. First, never rely on the placeholder as the accessible name — the single-space placeholder the float mechanism needs is intentionally empty, so the <label> must carry the text. Second, do not animate the label so small it fails contrast or so fast it violates reduced-motion expectations; keep the floated size legible and gate any transition behind motion-reduce:. The label element stays in the DOM the whole time, so its accessible name is stable whether floated or resting.

Not with the placeholder trick, because <select> has no placeholder attribute — :placeholder-shown never applies, so the usual peer-placeholder-shown: rule has nothing to hook onto. Demo 08 solves it with the constraint-validation API instead. The select is marked required and its first <option> is an empty-value placeholder option, which means the control is :invalid while nothing real is chosen and :valid once the user picks an option. You then drive the label from validity: a peer-invalid: variant holds the resting position, and the field floating up on peer-focus: or once it becomes peer-valid:. The one gotcha is that a native select is always "filled" visually, so you must keep that first empty option present and never give it a real value — otherwise the field reads as valid immediately and the label floats before the user has chosen anything.

iOS Safari auto-zooms whenever a focused input's font size is below 16px, which yanks the whole layout around and is jarring on a form. The rule is simply that the input's rendered font size must be at least 16px at the moment of focus — a 14px field will zoom no matter what else you do. Demo 13 sets the field type at 16px and, crucially, sizes the form to itself with @container rather than the viewport, so the breakpoints that shrink padding and spacing on a narrow screen never drag the input's font below the zoom threshold. Keep any responsive type scaling on the label and surrounding chrome, not on the input text. If you must show a visually smaller field, scale it with the box and letter-spacing but hold the font-size at 16px. This also means testing on a real device or the iOS simulator — desktop Chrome will never reproduce the zoom, so a passing desktop check tells you nothing here.

Demo 06 does this with the user-interaction validity pseudo-classes, which are the key to not shouting at someone mid-typing. A plain :invalid selector is true the instant an empty required field renders, so a naive rule paints every field red before the user has touched anything. Instead it uses peer-user-invalid: and peer-user-valid:, which only apply after the field has been interacted with and blurred. So the border, the floated label and the helper message all turn red on peer-user-invalid: once the user leaves an invalid field, and green on peer-user-valid: when the value satisfies the field's pattern or type. Wire the message element through aria-describedby so the state change is announced, not just coloured. The whole thing is CSS driven by the input's own constraint attributes — required, type="email", pattern — so there is no validation code to keep in sync.

The collision happens because both the icon and the label want the same left edge of the field. Demo 12 fixes the geometry rather than fighting it. The inline SVG icon is absolutely positioned inside the field and given a fixed lane, and the input gets left padding equal to that lane so the typed text starts clear of the icon. The label is then offset by the same amount at rest — its peer-placeholder-shown: position starts to the right of the icon, aligned with where the text will be, so nothing overlaps. When the field floats, the label lifts to the top edge on peer-focus: and can slide back to the box's real left edge, since the icon lane no longer matters up there. Mark the decorative icon aria-hidden so it is not announced. The reusable lesson: pad the input for the icon, offset the resting label by the same distance, and let the floated label ignore the lane entirely.

Floating labels are elegant but they trade away persistent guidance, so skip them where the field needs a hint the user must see while typing. Because the label doubles as the placeholder, once the field is focused the resting text is gone — if you also need format help like "MM/YY" or "include a country code", that has to live in a separate aria-describedby hint, not the label, or the user loses it exactly when they need it. They also compress the label into a small floated size, so long labels truncate; a field that needs a full sentence of context is better with a static label above it. And on a dense multi-column form like the checkout grid in demo 16, sixteen animating labels can read as busy — a plain top-aligned label scans faster there. Rule of thumb: use floating labels for short, self-explanatory fields (email, name, password) where the space saving matters, and fall back to a static <label> above the field whenever the label is long or the field needs ongoing formatting guidance.