Frontend Beauty
ESC

Type to search the knowledge base.

useId for Accessibility IDs

useId generates stable unique IDs for label/input wiring that work with SSR and hydration.

beginner3 min read
  • react
  • useid-for

Accessible forms need stable ids so <label htmlFor> matches <input id>, and so aria-describedby points at error text. Hard-coding "email" breaks when two instances mount. Math.random() breaks hydration. useId is the React-provided answer.

Docs: useId.

Basic field

function TextField({ label, error, ...props }) {
  const id = useId();
  const errorId = `${id}-error`;

  return (
    <div>
      <label htmlFor={id}>{label}</label>
      <input
        id={id}
        aria-invalid={Boolean(error) || undefined}
        aria-describedby={error ? errorId : undefined}
        {...props}
      />
      {error && (
        <p id={errorId} role="alert">
          {error}
        </p>
      )}
    </div>
  );
}

Multiple related ids from one hook call by suffixing — do not call useId in a loop; call once per component instance and derive.

Why not random or incrementing modules

Approach Problem
Math.random() Server HTML ≠ client HTML → hydration mismatch
Module-level counter Can diverge under streaming / multi-request SSR if not careful
Hard-coded string Collides when component used twice
useId Stable per instance across SSR and client

Not for list keys

// Wrong
items.map((item) => <Row key={useId()} />) // hooks in loop — illegal and useless

Keys come from data identity, not useId. See keys.

Interview out-loud

“useId returns a unique id stable across server and client renders so I can wire label, input, and aria-describedby without hydration mismatches. I derive multiple related ids with suffixes from one useId call, and I never use it as a list key.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides