A CSS input field is a styled text-input control where users type information into a form. These 28 hand-coded designs are ready-to-ship inputs for sign-up forms, search bars, settings screens, and checkout flows — copy the markup, drop into your form, and ship.
Classic floating label input. The placeholder lifts and shrinks above the field on focus — a calm, accessible pattern used across every modern product surface.
Material-style notched outline. The label sits inside a gap cut into the border. Subtle, professional, and works beautifully for forms with dense fields.
Search input with a leading magnifier icon and a trailing clear button. The clear control appears only when the field has content — handled with `:placeholder-shown`.
One-time-passcode entry split across six boxes inside a single `<fieldset>`. Auto-advance, backspace step-back, and full paste-to-fill — `autocomplete="one-time-code"` drives SMS auto-suggest.
The native placeholder attribute itself rotates through four sample queries every 2.5 seconds — "Search products…" → "Search docs…" → "Search people…" → "Search settings…". Light JS swaps the attribute; the browser does the rest. Stops the moment the user focuses or starts typing.
Type a tag and press Enter or comma to commit it as a chip. Backspace on an empty input removes the last chip — a polished pattern for filters and email recipients.
Drag-and-drop file input with a custom dashed boundary. Native `<input type="file">` underneath, the visible filename appearing via `:has()` — accessible, keyboard-friendly, and minimal.
Right-aligned numeric input with an inline `$` prefix. `inputmode="decimal"` brings up the right mobile keyboard; `:focus-within` lights the prefix to match the field accent.
A styled `<input type="date">` keeps every native picker behaviour (keyboard, accessibility, browser/OS calendars) while the chrome matches the rest of your form. `::-webkit-calendar-picker-indicator` is recoloured to match the accent.
Two `<input type="time">` paired with a typographic `→` divider. Single visual unit while remaining two independent fields for keyboard nav and form submission.
A `<input type="color">` swatch chip paired with a hex text field — both accept the same `name` and submit value via the underlying form. Sibling-`+` selectors mirror the swatch state.
Search field with a microphone trigger that toggles a recording state — pulses a halo while "listening". Real `<input type="search">` so AT announces it as a search field.
When the user types `@`, common email domains are suggested in a keyboard-navigable dropdown. `aria-controls` + `aria-expanded` + `role="listbox"` make it a proper combobox.
A multi-line `<textarea>` that grows with its content using `field-sizing: content` — no JS observer needed. Falls back to a min-height on browsers without support.
Click-to-edit text that swaps between a static value and an editable input. Saves on Enter, cancels on Escape, blurs to commit — the canonical pattern from Notion and Linear.
A native `<input type="range">` with custom track/thumb styling and a live value bubble that follows the thumb. Honest accessibility — keyboard arrows, screen-reader announcement, real form value.
URL input with a non-editable `https://` prefix that visually integrates with the field. Submit value is the full URL; users only type the host portion.
Password field with an eye toggle that swaps `type="password"` ↔ `type="text"`. `aria-pressed` reflects state for screen readers; `autocomplete="new-password"` for sign-up flows.
Bold offset-shadow stamp with hard edges and monospace type — a confident input that doesn't apologize for itself. Press collapses into the shadow on focus.
Style the native input element directly using its tag plus a class. Reset border, padding, background and font with a single rule, then add :focus and :focus-within states for the active look. Use :placeholder-shown to detect empty fields, :has() to react to descendant state, and :valid / :invalid for live validation feedback — all without JavaScript.
Are these CSS input fields accessible?
Yes. Every demo uses a real native input or textarea, paired with a real label (either visible or visually-hidden via .sr-only). Autocomplete attributes are set correctly (email, current-password, new-password, one-time-code, cc-number, tel) so password managers and SMS autofill work. Focus states are visible and keyboard navigation is the default browser behaviour.
What's the most accessible way to do a floating label?
Keep the label as a real label element associated with the input via for=id. Drive the floated state with the :placeholder-shown pseudo-class — the label moves up when the input is non-empty or focused. This way assistive tech still announces the label as the input's accessible name.
Do these inputs need JavaScript?
Most don't — 18 of the 28 are pure CSS using :focus-within, :placeholder-shown, :valid, :has() and adjacent-sibling selectors. The other 10 (OTP, tag input, inline edit, voice search, email suggestions, credit card formatter, etc.) include small self-contained JS snippets in the JS tab of the code panel.
Will autofill and password managers work with these inputs?
Yes. Each input keeps the native element with the correct type and autocomplete attribute. The custom styling never breaks 1Password, Bitwarden, Chrome autofill, or Safari's SMS auto-suggestion.