Search Input

Search field with a leading magnifier and a trailing clear (✕) that appears as soon as there is text, empties the field, and puts focus back so typing can continue. Reach for it wherever typing narrows what is on screen: above a filterable list or a data table, in a sidebar or a settings page, over the options of a dropdown or combobox, in docs and help search, in an admin record lookup, in a file or media library, over a long list of teams, projects or integrations, in a picker inside a dialog, and anywhere a "/" shortcut is meant to land in a search box. Common asks it answers: "search input", "search bar", "search box", "filter input", "clearable input", "input with a clear button react", "search field with icon", "type to filter a list", "table search box", "searchbar component", "shadcn search input", "shadcn input with clear button", "MUI TextField with clear button equivalent", "antd Input.Search equivalent", "chakra InputRightElement clear equivalent", "clear button does not trigger onChange react", "setting input.value does not fire onChange", "React set input value programmatically and fire change", "hide the native search cancel button", "focus the search box with a slash shortcut", "debounce a search input nextjs". Official shadcn/ui has nothing for this: onClear, clearable, search-cancel, nativeInputValueSetter, HTMLInputElement.prototype, dispatchEvent, searchValue and type="search" are each zero hits across all 62 of its fetchable items (measured 2026-09-26) — its input is a bare styled <input>, and its input-group is a layout kit of six parts (InputGroup, InputGroupAddon, InputGroupButton, InputGroupText, InputGroupInput, InputGroupTextarea) pulling in button, input and textarea, handing you slots to hang your own icon and clear control in. You still write the clear button, the show-it-only-when-there-is-text rule, the refocus and the event plumbing. This is that already assembled, in one import. Distinct from the pulld pieces it sits beside: command-palette is a modal that takes over the screen and runs commands, this is a field that stays on the page; filter-chips shows the conditions already applied and takes them off one at a time, while this is the one condition a person is typing; multi-select and tag-input collect values into a field rather than narrowing a list outside it; mention-input searches inside prose after an @; speech-input is the same job by voice; and highlight-text is what marks the matches in the results this produces. Pairs with all of them — a query in the URL that this field writes is a chip filter-chips can take off again. The part that is easy to get wrong is clearing. Assigning to the input's value does not make React's onChange fire, so a hand-rolled clear button empties the box while the list behind it stays filtered on the old query — the field looks reset and the results do not agree. This writes through the native value setter and dispatches a bubbling input event, so onChange fires for controlled and uncontrolled use alike and whatever filtering it drives actually updates. It also hides the WebKit search-cancel button so there is not a second ✕ beside the first, keeps the magnifier out of the accessibility tree and out of pointer events, gives the clear control a screen-reader label, and passes only one of value/defaultValue through so React never warns about a field switching between controlled and uncontrolled. The clear button is deliberately left out of the tab order, so Tab moves on to the next field rather than into a control that duplicates select-all-and-delete. Standard input props and a forwarded ref pass straight through, so a "/" hotkey can focus it. Theme-aware via shadcn tokens; depends only on lucide-react.