React Label Component Examples

The most common form field is a Label above an Input. Wrap both in a flex flex-col gap-2 container so the Label sits on its own line eight pixels above the Input. Pass htmlFor="email" on the Label and id="email" on the Input, and the browser focuses the Input when the user clicks the Label text — no JavaScript runs, no React handler fires, the focus forwarding is part of the platform. The Drivn Label's default classes — text-sm font-medium text-foreground — give the Label a quiet visual weight that does not compete with the Input below it.

The pattern scales to any stacked field — a textarea, a date picker, a Select, a custom file uploader. The Label sits at the top, the control sits below, the wrapper handles spacing. If the form grows to multiple stacked fields, wrap the whole form in a flex flex-col gap-6 container so each field group has consistent vertical rhythm between rows.

For opt-in patterns like terms acceptance or newsletter subscription, the Label sits next to the Checkbox on the same line. Wrap both in a flex items-center gap-2 container — the inline-flex layout centers the Label text vertically against the Checkbox box, and the eight-pixel gap separates them. Pass htmlFor="terms" on the Label and id="terms" on the Checkbox, and clicking the Label toggles the Checkbox just like clicking the box directly.

This is the standard pattern for terms-of-service rows, marketing opt-ins, "remember me" toggles on sign-in forms, and feature flags inside settings pages. The Label's text-sm font weight keeps the line readable without shouting, and the click target extends across the whole row because the native <label> element receives clicks for its entire bounding box. The same wrapping pattern works with the Drivn Switch component for opt-in flows that prefer a toggle aesthetic over a checkbox.

A typed dropdown like a framework picker pairs a Label above a Select. The same stacked layout pattern applies — flex flex-col gap-2 wrapper, Label on top, Select below — but the htmlFor/id pair attaches to the Select.Trigger rather than the root Select component because the Trigger is the focusable element that owns the field. Pass id="framework" on the Select.Trigger and htmlFor="framework" on the Label, and the click forwarding lands on the Trigger button.

The Drivn Select uses dot notation — Select.Trigger, Select.Menu, Select.Option — so the whole field reads as one cohesive group from a single Select import. The Label sits outside the Select component, which keeps the field description visually distinct from the dropdown surface and gives screen readers a clean <label for="framework">Framework</label> reference to the focusable Trigger. Pair this with the Combobox component when the dropdown needs typeahead search.

A radio group needs one Label per option plus one heading Label for the whole group. The heading Label sits at the top with no htmlFor because it labels a fieldset rather than a single control — wrap the group in a <fieldset> element and pair the heading with a <legend> for semantic correctness, or render the heading Label as a plain group title above the options. Each option Label sits next to its Radio item with htmlFor pointing at the radio's id.

The layout is two nested flex containers — an outer flex flex-col gap-3 for the heading and the option list, and an inner flex flex-col gap-2 for the stacked option rows. Each option row is flex items-center gap-2 with the radio on the left and the option Label on the right. The pattern works for plan pickers, theme selectors, payment method choices, and any single-choice form field where the options stack vertically. Use the Drivn Tabs component instead when the options act as filters rather than form input.

A required-field marker reads as a red * next to the Label text. Add the marker as a child of the Label rather than as a separate sibling — the marker stays visually attached to the Label, the click target on the marker also forwards focus to the Input, and the screen reader announces the glyph as part of the Label text. Wrap the marker in a <span className="text-destructive" aria-hidden="true"> so the visual contrast is clear and the assistive technology relies on the explicit aria-required="true" on the Input rather than parsing the character.

The Label's default classes already use text-foreground, so the marker picks up the destructive HSL token without affecting the rest of the Label text. Pair this with the form's validation logic in react-hook-form or zod to enforce the required constraint at submit time. The marker is purely a visual cue — the actual validation lives in the form schema and surfaces as an error message below the Input.

Drivn's Label carries no disabled styling. Its className is text-sm font-medium text-foreground and nothing more, which means a disabled field does not fade its label until you say so. shadcn/ui takes the other route and bakes peer-disabled:cursor-not-allowed peer-disabled:opacity-50 into the recipe — that works while the disabled control is a sibling carrying the peer class, and quietly does nothing the moment your markup nests differently.

The explicit version is a conditional className at the call site: className={isDisabled ? "opacity-50 cursor-not-allowed" : undefined}. Drive it from the same boolean that disables the Input so the two can never disagree — a useState flag, a formState.isSubmitting value from react-hook-form, or a request-in-flight boolean. When a form grows to a dozen fields, lift that flag into a small field context and read it inside a wrapper component instead of repeating the ternary on every row. Because the Label source lives in your repo after install, adding a real disabled prop to the file is equally fair game. See Drivn vs shadcn Label for how the two defaults compare in practice.