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 keeps the Label layout-neutral and does not bake in peer-disabled styling. To fade the Label when its associated control is disabled, pass a conditional class at the call site — className={isDisabled ? "opacity-50 cursor-not-allowed" : undefined} — or wire a disabled prop through your own extended Label file. Both approaches are explicit edits in your repo because the Label source lives there after install. The trade is a small amount of repetition at the call site versus an assumed sibling-relationship convention.

The Input itself handles its own disabled visuals via the disabled attribute, so the Label only needs to mirror the visual state. Pair this with a useState boolean or a form state value from react-hook-form to drive the disabled flag from one source of truth. For a more centralized approach across many fields, wrap the field in a parent that exposes a disabled context and have the Label read from it. See the Drivn vs shadcn Label comparison for how the two libraries differ on this exact decision.