Why can a React <input type="file"> not be a controlled component, and how do you read and clear the user's selection?

## The security rule underneath If a page could set a file input's value, any site could read arbitrary files off your disk by pointing an input at a path and submitting the form. The platform therefore makes the selection user-only: setting `input.value` to a non-empty string is rejected, and the only assignment the browser honours is the empty string, which clears the selection. That rule collides directly with React's controlled pattern, whose whole premise is that React writes the value onto the node every render. There is nothing React can do about it, so a file input is always uncontrolled — render it with no `value` prop and let the DOM own the choice. ## Reading the selection The interesting data is not the value string (a browser-sanitised fake path) but the `files` property, a `FileList` of `File` objects: ```jsx function Upload() { function handleChange(e) { const file = e.target.files[0]; if (!file) return; // the user cancelled the picker console.log(file.name, file.size, file.type); } return <input type="file" onChange={handleChange} />; } ``` With `multiple`, iterate the whole list — `Array.from(e.target.files)` turns it into a real array. Outside a change handler, a ref gives you the same thing: `inputRef.current.files`. And a `FormData` built from the surrounding form returns `File` objects for that field rather than strings, so the same field reads differently from every other one in the form. Always guard for an empty list. Opening the picker and cancelling leaves `files` empty, and on some platforms it fires a change event, so `files[0]` can be `undefined`. ## Uncontrolled input, controlled UI "Uncontrolled" applies to the input element, not to your component. Keeping the selection in state is normal and useful: ```jsx const [file, setFile] = useState(null); <input type="file" onChange={(e) => setFile(e.target.files[0] ?? null)} /> {file && <p>{file.name} ({Math.round(file.size / 1024)} KB)</p>} ``` State here holds a `File` object you use to render a filename, a size, a preview or an upload progress row. It is never fed back into the input's `value`, which is exactly why this does not count as controlling the input. For an image preview, `URL.createObjectURL(file)` gives you a URL to render, and you release it with `URL.revokeObjectURL` when the preview goes away. ## Clearing the field Two approaches, both legitimate: ```jsx // 1. the one assignment the browser allows inputRef.current.value = ''; // 2. throw the element away and mount a fresh one <input type="file" key={resetCount} onChange={handleChange} /> ``` The first is direct and cheap. The second is useful when several fields reset together — bumping a counter used as a `key` discards the old input and mounts a new, empty one. Calling `form.reset()` on the surrounding form clears file inputs too, along with everything else. ## The gotcha worth mentioning A change event fires when the *value changes*. Pick `report.pdf`, upload it, then pick `report.pdf` again and nothing happens — the value did not change, so no event, so your handler never runs and the UI looks frozen. Clearing the input right after you have consumed the file (`e.target.value = ''` at the end of the change handler) makes every subsequent pick a change, including re-picking the same file. Interviewers like this one because it only shows up in real usage. ## What to say in an interview Lead with the reason rather than the rule: the file selection is user-controlled for security, so `value` is not assignable and the controlled pattern cannot apply. Then the practicalities — read `files`, keep the `File` in state if the UI needs it, clear with `value = ''` or a `key` remount — and finish with the re-picking-the-same-file gotcha, which shows you have shipped an upload flow rather than read about one.