Controlled vs uncontrolled inputs: who owns the value, and what it costs

Two owners, one input

Every form field has exactly one source of truth, and React makes you choose which. In a controlled input, React state owns the value: the value prop pins what the DOM shows, and onChange is the only door through which a keystroke becomes visible — the event fires, you call setState, React re-renders, and the new value flows back down into the DOM. The DOM input is reduced to a dumb display of your state. In an uncontrolled input, the DOM owns the value, exactly as it would in a plain HTML page: the browser tracks what the user typed, React never hears about individual keystrokes, and you read the result when you need it — via a ref, or all at once with new FormData(form) in the submit handler. defaultValue (not value) seeds the initial text without claiming ownership.

The distinction is not stylistic; it decides when your code runs. Controlled means your component re-renders on every keystroke — that is the price of admission. Uncontrolled means your component renders once and your code runs at submit time.

function CouponControlled() {
  const [code, setCode] = useState("");
  // Re-renders per keystroke; can validate, transform, disable live.
  return (
    <input
      value={code}
      onChange={(e) => setCode(e.target.value.toUpperCase())}
    />
  );
}

function CheckoutUncontrolled() {
  // Renders once; the DOM holds the values until submit.
  function handleSubmit(e) {
    e.preventDefault();
    const data = new FormData(e.currentTarget);
    submitOrder(data.get("coupon"), data.get("email"));
  }
  return (
    <form onSubmit={handleSubmit}>
      <input name="coupon" defaultValue="" />
      <input name="email" type="email" />
      <button>Pay</button>
    </form>
  );
}

What controlled buys you, and what it bills you

Choose controlled when the UI must react to the value as it changes: live validation messages, a character counter, formatting-as-you-type (card numbers in groups of four), filtering a list on each keystroke, enabling the submit button only when the form is valid, or keeping two widgets in sync with the same value. None of that is possible if React only learns the value at submit.

The bill arrives as render work. One controlled input re-rendering its own small component is nothing — a render is a function call producing elements, well under a millisecond. The failure mode is structural: teams lift all field state into one object at the top of a 60-field form, so every keystroke in any field re-renders the entire form tree. At 5–15 ms per full-form render that still fits a frame; add a few expensive child components and you reach 40–80 ms per keystroke — and typing visibly stutters, because each keystroke now triggers layout-sized work. The fixes are also structural: keep field state in the smallest component that needs it, memoize heavy siblings, or stop controlling fields that nothing reads before submit.

Choose uncontrolled when the form is submit-shaped: nothing depends on intermediate values, you want minimal re-render cost, you are integrating a non-React widget that mutates the DOM itself, or you handle file inputs — <input type="file" /> is always uncontrolled, because its value can only be set by the user, never by code.

The half-controlled input: how the modes corrupt each other

Two failure modes account for almost every form bug in this area. First: value without onChange. The input becomes controlled by a constant. The user types, the DOM briefly shows the character, React re-renders (or just resets the node) back to the pinned value — the field eats keystrokes. React warns once in the console and offers the legal escapes: add onChange, use readOnly if it is genuinely read-only, or use defaultValue if you only meant to seed it.

Second: switching modes during the component’s life. An input mounts uncontrolled (value is undefined — perhaps the profile data has not loaded yet) and later receives a string once the fetch resolves. React logs: A component is changing an uncontrolled input to be controlled. The danger is not the warning text; it is that whatever the user typed during the uncontrolled window is silently obliterated when the value prop takes ownership. The inverse switch (controlled → uncontrolled, value becomes undefined) abandons the field with its last value frozen. The rule: an input is controlled or uncontrolled for its whole lifetime. If your initial state may be absent, initialize to "", never undefined — or do not render the input until the data exists.