Explain controlled vs uncontrolled React form inputs and trade-offs

Tests state versus DOM ownership. Controlled inputs bind to React state via onChange; uncontrolled inputs read from DOM via refs. Trade-offs: reactivity, validation, complexity. Red flag: saying uncontrolled is easier while ignoring lost live validation.
WHAT THIS TESTS: Whether you understand React's core philosophy of declarative UI driven by state versus imperative DOM manipulation. The interviewer wants to see that you recognize React re-renders based on state changes, so an input whose value lives only in the DOM is invisible to React's rendering logic until you explicitly pull it out.
A GOOD ANSWER COVERS: Four things in order. First, the definition of a controlled component: the input value is bound to a React state variable via the value prop, and every keystroke flows through an onChange handler that calls a state setter, making React the single source of truth. Second, the definition of an uncontrolled component: the input manages its own value internally using the DOM, and you access it only when needed via a ref or a form submit event, similar to traditional HTML forms. Third, the trade-offs in concrete terms: controlled gives you instant validation, the ability to transform input, and conditional UI that reacts to every character, but it costs extra state variables and re-renders; uncontrolled minimizes boilerplate for simple forms but breaks real-time reactivity, makes cross-field validation harder, and can create stale UI because React does not know the value changed. Fourth, when to pick each: controlled for dynamic forms, wizards, or any input that drives other UI; uncontrolled for file inputs, integrating non-React widgets, or truly static simple forms.
COMMON WRONG ANSWERS: Saying uncontrolled is always easier or more performant because it avoids re-renders. This misses that React re-renders are cheap and that losing synchronization with the DOM causes more debugging pain than the extra state overhead. Another red flag is claiming controlled components require useState for every input; a great candidate mentions batching, form libraries, or reducers for scaling. Finally, do not say refs are forbidden in React; they are a valid escape hatch, just not the default for form data.
LIKELY FOLLOW-UPS: How would you handle a form with fifty controlled inputs without fifty useState calls? The expected direction is using a single state object, a reducer, or a form library like React Hook Form. Another follow-up: how do you reset an uncontrolled input? The answer is manipulating the DOM node directly through a ref, which highlights why React prefers state. They may also ask about file inputs, which must be uncontrolled because their value property is read-only, making them a canonical exception.
ONE CONCRETE EXAMPLE: Imagine a credit-card entry form. Controlled: you store cardNumber in state, onChange strips spaces and validates length in real time, and a disabled prop on the submit button reads state to enforce the form is complete. Uncontrolled: you add a ref to the input, the user types freely, and on submit you read ref.current.value once; you cannot disable the submit button based on partial input because React has no visibility into the keystrokes.
Source: react.dev
Read the original → react.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.