The useId Hook

In one minute

A <label htmlFor="x"> focuses the input with id="x", and ids must be unique on the page. A reusable Field component can’t hard-code its id (it may render many times) and shouldn’t force every caller to invent one. useId() returns an id that is unique for each component instance and identical on the server and in the browser, so it also works with server rendering, which a counter or Math.random() doesn’t.

You’ll be able to: connect labels and inputs (and aria-* attributes) safely in reusable components.

1function Field({ label, ...props }) {2  return (<div>3    <label htmlFor="review-title">{label}</label>4    <input id="review-title" {...props} />5  </div>)6}

1function Field({ label, ...props }) {2  const id = useId()3  return (<div>4    <label htmlFor={id}>{label}</label>5    <input id={id} {...props} />6  </div>)7}

The example: two review forms on one product page

Hard-coded id

function FieldHardcoded({ label, ...props }: { label: string } & ComponentProps<'input'>) {
	return (
		<div>
			<label htmlFor="review-title">{label}</label>
			<input id="review-title" {...props} />
		</div>
	)
}

Both review forms render two Fields. The ids in the page:

[
  [
    "review-title",
    "review-title"
  ],
  [
    "review-title",
    "review-title"
  ]
]

The recorder clicked the label “Your name” in the Desk Lamp form. What received focus:

{
  "form": "Ceramic Mug",
  "field": "title"
}

The wrong field in the wrong form: with duplicate ids, the browser uses the first matching element.

useId

function Field({ label, ...props }: { label: string } & ComponentProps<'input'>) {
	const generatedId = useId()
	const id = props.id ?? generatedId
	return (
		<div>
			<label htmlFor={id}>{label}</label>
			<input {...props} id={id} />
		</div>
	)
}

[
  [
    "_r_0_",
    "_r_1_"
  ],
  [
    "_r_2_",
    "_r_3_"
  ]
]

{
  "form": "Desk Lamp",
  "field": "author"
}

Every field got its own id, and the label focused its own input. A caller can still pass an explicit id; the component only falls back to the generated one.

How it works

• The id comes from the component’s position in the tree, not from a counter. Server and client render the same tree, so they produce the same ids, and hydration matches. A module-level counter can differ between server and client (separate runtimes, different hydration order); Math.random() always does.
• It’s stable for the life of the component: re-renders return the same string. There’s no setter because it never needs to change.
• One call, many ids: derive related ids from it (${id}-hint, ${id}-error) for aria-describedby.
• Several React roots on one page can pass identifierPrefix to createRoot / hydrateRoot (and the matching server API) so their ids don’t collide.

Common mistakes

• Using useId for list keys. Keys must come from the data (Rendering Arrays).
• Hard-coded ids in reusable components.
• Generating ids with a counter or Math.random() in apps that render on the server.

Interview Q&A

Related

• Forms and Inputs (Fundamentals): labels and accessible fields.

Sources

• react.dev: useId, hydrateRoot identifierPrefix
• Topic order inspired by Kent C. Dodds’ EpicReact React Hooks workshop; the example app and code here are this handbook’s own.

Primary source: react.dev/reference/react/useId