Anatomy, proportion, and shape — the structural decisions that define a text field before a single keystroke occurs.
The label identifies the field. It is not optional — even when visually hidden, it must exist in the DOM for screen readers.
The border (or its visual equivalent — a background fill, a shadow, an underline) delineates the interactive region.
The inline padding creates breathing room between the border and the text. The value text is whatever the user has typed. The placeholder (not shown above) occupies the same space as the value but disappears on input. The hint text (also called helper text or description) provides supplementary guidance below the field.
Alternatives to hint text may be used when the field is in an error, warning, or success state. These include adornments such as icons, prefixes, suffixes, or action buttons embedded inside or alongside the input.
Like buttons, most design systems offer 3–5 input sizes. The logic is identical: scale the font-size and derive padding, radius, and icon dimensions proportionally. But inputs have an additional constraint that buttons don't — the input must remain comfortable to type into, not just to look at or click. This sets a practical floor on height and padding that's slightly higher than for buttons.
XS (28px) is viable only in dense toolbars and data tables where screen real estate is severely constrained. At this size, the text cursor can feel cramped and the tap target falls below the 44px minimum recommended by WCAG for touch devices. Use with caution and only on desktop.
SM (34px) works for compact UIs — admin panels, developer tools, secondary forms. Comfortable enough for short interactions but not ideal for extended data entry.
MD (40px) is the workhorse. Most design systems land here for their default input size. It provides a comfortable typing area, meets touch-target guidelines, and pairs naturally with standard-sized buttons. If you only pick one size, this is it.
LG (48px) is appropriate for hero inputs — search bars, sign-up forms, onboarding flows. The additional vertical space makes the field feel more inviting and gives the text room to breathe.
XL (56px) is rare in form contexts but appears in search-dominant interfaces where the input is the primary UI element — think Google's search bar or a command palette. The size communicates "this is the main thing you should do here."
The radius decision for inputs follows directly from buttons — if your buttons are 8px radius, your inputs should be 8px radius. This is not a suggestion; it's one of the strongest visual coherence signals in a design system. Mismatched radii between buttons and inputs is one of the most common tells of an uncoordinated system.
Sharp corners (0px) work in editorial and brutalist systems — they pair naturally with underline-only inputs and square buttons. The 4px radius is the minimum needed to soften the corners visually without making the field feel "designed." The 8px moderate radius is where most modern systems land and is the safest default. 12px rounds create a softer, more consumer-friendly feel.
The pill shape deserves special consideration for inputs. On buttons, the pill is common and unambiguous. On inputs, it introduces a subtle problem: as the field gets wider, the pill shape creates wasted space in the corners that text can never reach. On a narrow search input, this is fine. On a full-width form field, it looks peculiar. Most systems that use pill-shaped buttons still use moderate-radius inputs.
Buttons have fill variants — solid, outlined, ghost, tinted. Inputs have an analogous set of border strategies that define how the field's boundary is communicated to the user.
Outlined is the most common pattern and the most flexible. A continuous border clearly delineates the interactive area on any background. It provides three clear channels for state communication: border color, border width, and background color. Almost every design system uses outlined inputs as the default or sole option. If you're choosing one pattern, this is it.
Underline (also called "line" or "minimal") was popularized by Material Design and remains common in mobile-first interfaces. It's spatially efficient and elegant, but carries real tradeoffs: the interactive area is ambiguous (does the field extend to where?), and communicating states without a full border requires leaning more heavily on color and background changes. In practice, many systems that adopted underline inputs have migrated back to outlined, or supplemented the underline with a background fill on focus.
Filled uses a tinted background instead of a visible border to define the field. This reads clearly on white or light surfaces but can struggle on dark or tinted backgrounds where the fill contrast diminishes. Google's Material Design 3 uses filled inputs as a primary variant. The key tradeoff: filled inputs need a separate signal for focus (typically adding a border or intensifying the fill), since the resting fill already occupies the background channel.
Filled + underline combines both strategies — a tinted fill defines the field area while a bottom border provides a clear baseline. This is Material Design's "filled" variant and it works well: the fill establishes the region, the underline provides an anchor, and focus can thicken or recolor the underline without restructuring the field. The flat top / rounded bottom radius is distinctive but intentional — it prevents the field from looking like a button.
Elevated uses a box-shadow instead of a border to define the field edge. This creates a softer, more dimensional look that can feel premium. The tradeoff is that shadow is harder to intensify for focus and error states without looking heavy, and it can clash with other elevated elements (cards, modals) in the same interface.
Border weight on inputs follows the same logic as buttons. Hairline (0.5px) borders are elegant on Retina displays and pair well with minimal interfaces, but require a darker border color to remain visible. The 1px weight is the most common default. 1.5px provides slightly more definition without feeling heavy — this is where systems like Radix and shadcn/ui typically land. 2px borders feel deliberate and structural; they're appropriate for bold, graphic aesthetics but can feel heavy in long forms.
An important consideration for inputs specifically: the border often needs to change weight or color on focus. If your resting border is already 2px, your focus border either needs to get wider (which causes layout shift) or darker (which may not be enough contrast change). Starting with a thinner resting border — 1px or 1.5px — gives you more room to intensify on focus without layout consequences.
Button padding is a ratio — vertical to horizontal. Input padding follows the same logic but with a twist: the horizontal (inline) padding matters more, because it determines how close the user's text sits to the border. Text that touches or nearly touches the field edge feels cramped and uncomfortable during typing, even if it looks fine in a static mockup.
Tight padding works in data-dense contexts — table cells, compact filters, developer tools. The text feels close to the edges, which signals efficiency over comfort.
Balanced is the default for most systems. The inline padding (14px) provides enough clearance that text never feels crowded, while the block padding (10px) keeps the field from becoming taller than necessary.
Generous and Airy proportions suit marketing forms, sign-up flows, and settings pages where the form is the focal content, not a tool. The extra breathing room makes each field feel more important and less like a data-entry chore.
Unlike buttons, where the horizontal-to-vertical ratio can vary widely (from 1:1 in square icon buttons to 4:1 in wide CTA buttons), inputs tend toward a narrower ratio range. A useful rule: the inline padding should be between 1× and 1.5× the block padding. Less than 1× (more vertical than horizontal space) feels structurally wrong. More than 2× (very wide horizontal padding) wastes space and pushes the text away from the natural reading position.
Every text input needs a label, and where that label sits relative to the field is one of the most consequential layout decisions in form design. The placement affects form density, scanning speed, label-to-field association, and how the form responds to different viewport widths.
Labels above the field are the modern default and the strongest recommendation from UX research. The eye moves top-to-bottom in a single vertical scan — label, then field, then the next label. Research by Matteo Penzo (widely cited since 2006 and reconfirmed in subsequent eye-tracking studies) found that top-aligned labels produce the fastest form completion times because the eye doesn't need to shift horizontally between label and field.
Top-aligned labels also handle responsive design gracefully. They don't break or reflow when the viewport narrows. They accommodate long labels (common in enterprise software and localized UIs) without truncation. And they stack naturally into a single-column form layout that works from mobile to desktop.
Inline labels sit to the left of the field, creating a horizontal label–field pair. This is more compact vertically than top-aligned labels — a form with 10 fields takes roughly 40% less vertical space. The tradeoff is horizontal space: you need a consistent label column width, which means either truncating long labels or expanding the column to accommodate the longest one.
Inline labels work best when label text is short and consistent in length (settings forms, profile editors), when vertical space is constrained, and when the form is presented in a context where the user is already familiar with the fields. They work poorly on narrow viewports, with long or translated labels, and in unfamiliar forms where scanning speed matters more than density.
Floating labels start as placeholder text inside the field and animate upward to become a label when the field is focused or filled. This pattern was introduced by Material Design and has become widespread in mobile-first interfaces, especially in contexts where screen real estate is at a premium.
The advantages are real: floating labels achieve the density of placeholder-only fields (one line per field instead of two) while preserving label visibility after the user types. In a mobile sign-up form with 4–5 fields, this density savings can be the difference between a form that fits above the fold and one that requires scrolling.
The disadvantages are also real. The floating animation introduces motion at a moment when the user is trying to focus on typing — the label is moving at precisely the moment their attention should be settling. The floated-up label is necessarily small (typically 10–12px) which can be difficult to read for users with low vision. And the implementation is complex: the field needs asymmetric vertical padding (more top than bottom) to reserve space for the floated label, which changes the text's vertical position within the field.
Inset labels (sometimes called "notch" labels from Material Design's outlined variant) sit on the field's top border, interrupting it. This is a hybrid of top-aligned and floating — the label is always visible, sits close to the field for strong association, and doesn't consume a full line of vertical space above the field.
The visual effect is distinctive: the label creates a gap in the top border, which is achieved in CSS with a background-colored padding behind the label text. This works cleanly on solid backgrounds but becomes fragile on patterned or gradient backgrounds where the label's background patch is visible. It also complicates the implementation of border-radius on the input, since the notch interrupts the border at its most visible point.
Inputs often benefit from — and sometimes require — supplementary text that explains what's expected, what format to use, or what constraints apply. This hint text (also called helper text, description, or caption) sits below the field and is part of the input's total vertical footprint.
Hint text should be visually subordinate to both the label and the value text. The standard approach is a smaller font-size (12–13px when the field is 14px) in a muted color. It sits below the field with a small gap (4–6px) — close enough to associate with the field, far enough to not merge with the input text.
Character counters are a specialized form of hint text, typically right-aligned and set in a monospace or tabular-figure font. They're appropriate for inputs with explicit length limits (social media bios, SMS messages, database fields with varchar constraints). Avoid showing them on fields without meaningful limits — a character counter on a name field feels bureaucratic.
An important layout consideration: hint text occupies vertical space that validation messages will later need. When a field transitions from its resting state to an error state, the hint text is typically replaced by an error message. If you don't reserve space for this text in the resting state, the appearance of an error message will push all content below the field downward, causing a distracting layout shift. The two common solutions are: always render the hint text (even if empty, as a minimum-height container), or use fixed-height form rows that accommodate hint text whether visible or not.
Inputs frequently contain visual elements beyond the text itself — icons that indicate the field's purpose, icons that indicate the field's state, prefix or suffix text that provides context, or embedded action buttons.
Leading icons indicate the field's purpose — a search icon on a search field, an envelope on an email field, a lock on a password field. They're read before the input text and serve as a visual label supplement. Trailing icons indicate state or provide an action — a checkmark for valid, an × for clearable, an eye toggle for password visibility. They're read after the input text.
The sizing rule is the same as for button icons: the icon should match the cap-height of the input text, typically 16px for a 14px font. The icon is positioned with position: absolute inside a wrapper, and the input's padding is increased on the adorned side to prevent text from overlapping the icon. A common pattern: if the input has 14px inline padding, the icon sits at 14px from the edge, and the input's padding on that side increases to 14px + icon-width + 8px gap = 38px.
Prefixes and suffixes are text elements that sit inside the field boundary but outside the editable area. They provide context that's constant — a URL protocol, a currency symbol, a unit of measurement. Unlike icons, they're textual and share the input's typographic baseline.
The visual treatment typically differentiates the affix from the input text through a tinted background and a dividing border. This makes it clear that the affix is not editable. Some systems skip the tinted background and use only color differentiation (muted text), which is more minimal but can be ambiguous about editability.
A structural note: affixes are best implemented as a wrapper element that contains both the affix spans and the input, with the shared border on the wrapper and no border on the input itself. This avoids the visual problem of nested borders and ensures the border-radius curves cleanly around the entire composite element.
Inputs and buttons frequently sit side by side — a search input with a submit button, an email field with a subscribe button, a filter input with an apply action. When they do, their heights, vertical padding, and border treatments must align precisely. This sounds trivial but is one of the most common source of subtle visual bugs in production interfaces.
The alignment problem has a simple root cause: inputs and buttons typically have different default styles, even within the same design system. The input might use 1.5px borders while the button uses none (solid fill). The input might have 10px block padding while the button has 12px. These small differences compound into visually misaligned heights.
The solution from Part II of the Button Taxonomy applies directly: always declare a border on both elements, even when one is transparent. If your button has border: 1.5px solid transparent and your input has border: 1.5px solid #c8c5be, their box models match. Combined with identical padding values and identical font-size, the two elements will be exactly the same height.
Note that the button's horizontal padding can differ from the input's — it usually should, since button labels benefit from more generous inline spacing. The critical alignment properties are font-size, line-height, block padding, and border-width. As long as these four match, the elements will be the same height regardless of their horizontal proportions.
HTML provides over 20 input types, each with different native behaviors, browser-rendered UI, and styling constraints. Understanding what you can and can't control is essential before committing to a visual system.
The types above fall into three categories based on styling control:
Fully stylable — text, email, password, tel, url, search, number. These accept all CSS properties including padding, border, background, font, and color. They are the primary targets of your input design system. The search type has one quirk: some browsers add a cancel button (×) that has limited styling control via ::-webkit-search-cancel-button.
Partially stylable — date, time, datetime-local, month, week. These render browser-native picker UI (calendar dropdowns, clock selectors) that cannot be styled with CSS. You can style the text display and the outer box, but the dropdown is browser-controlled. Many design systems replace these entirely with custom components, which provides visual consistency at the cost of accessibility and mobile keyboard optimization.
Replacement candidates — select, file, range, color. These have such limited styling control that most design systems replace them with custom components. The native select, for example, only allows styling of the closed state on most browsers — the dropdown menu itself is OS-rendered. Custom selects are nearly universal in production design systems, though they require careful ARIA implementation to preserve accessibility.
Full width is the simplest and most common approach: the input stretches to fill its container. This works well in single-column forms and is the easiest to implement responsively. The tradeoff is that very wide inputs (600px+) can feel empty and disconnected from their labels, especially with short content like zip codes or phone numbers.
Fixed width communicates the expected content length. A 100px-wide zip code field signals "short input expected" more clearly than a label ever could. This is a powerful affordance but requires manual tuning per field, which makes it harder to maintain in large forms and breaks down on narrow viewports where the fixed width may exceed the available space.
Grid-based width — assigning fields to grid columns (50%, 33%, 25%) — is the most sophisticated approach. It communicates grouping (first name / last name on the same row), content length (a short field in a narrow column), and visual hierarchy (a full-width field below a row of half-width fields). Most modern form libraries support grid layouts with responsive breakpoints that collapse multi-column rows to single-column on narrow viewports.
A practical recommendation: use full-width as your default, then override to fixed or grid widths only when the field's expected content justifies it. Zip codes, country codes, and CVV fields benefit from narrow widths. Name, email, and address fields work well at full width. Date ranges and city/state/zip combinations are natural candidates for grid rows.
This has been the static anatomy — the decisions you make about an input before any interaction occurs. But an input that doesn't respond to interaction is just a rectangle with text in it. The next documents in this series will address the problems that make input design genuinely difficult:
Part II: States & Focus — the full state matrix (empty, filled, focused, disabled, read-only, valid, invalid) and the combinatorial problem they create. The focus ring as a sustained-viewing element. Placeholder text: when to use it, when to avoid it, and how to style it. The caret and selection styling.
Part III: Color & Validation — semantic colors for success, warning, and error states. How the validation palette interacts with the base monochrome system. Dark mode token architecture for inputs. The transition timing between states.
Part IV: Composition & Layout — form layout patterns (single-column, multi-column, sectioned). Fieldsets and legends. Input groups (connected inputs that share a border). The relationship between form density and user task type.
Part I of the Input Taxonomy. The companion series to the Button Taxonomy (Parts I–IV).
The best input is the one that disappears — the user thinks about their data, not the field.