Mobile Search Screen — Free HTML CSS JS UI Snippet

A search screen has two faces — a resting state with recent searches and trending queries, and an active state that filters results live as you type. This snippet builds a complete, interactive one inside a CSS phone frame: typing filters a catalog and highlights the matched substring, recent chips and trending rows prefill the query, a cancel button slides in on focus, and a no-results state names what you searched — in HTML, CSS, and vanilla JavaScript with no dependency.

Two states from one input

When the field is empty, the default view shows recent-search chips and a ranked trending list; the moment you type, that view hides and a results list takes its place. A single run() function reads the input, decides which view to show, and renders — so every entry point (typing, tapping a chip, tapping a trend row) funnels through the same logic and the screen stays consistent.

Live filtering with highlighted matches

Typing filters a catalog array by a case-insensitive substring test, then renders each match with the matched portion wrapped in a <mark>. The highlight is built by replacing the query with a captured group using a RegExp, and the query is escaped first so special characters like . or ( cannot break the pattern — the safety step most naive highlighters miss. Each result shows an icon, the highlighted name, and its category.

The sliding cancel button

Focusing the field slides a Cancel button in from zero width using a max-width and opacity transition, and tapping it clears the query, blurs the field, and returns to the default view — the exact iOS search-bar behavior. A small clear (×) button inside the field appears only when there is text.

Prefill from recent and trending

Recent searches are tappable chips and trending queries are a ranked list with a rising-percentage badge; tapping either drops its text into the input and runs the search immediately, so common queries are one tap away. The "Clear" action empties the recent list and leaves a quiet placeholder in its place.

A named empty state

When nothing matches, the results are hidden and a message echoes the exact query — "No results for …" — so the user knows the search ran and simply found nothing, rather than staring at a blank screen wondering if it is loading.

Accessibility and performance

The field is a real text input and the recent chips, trending rows, cancel, and clear controls are all buttons, so the screen is fully keyboard-operable. When you adapt this, wrap the results region in an aria-live="polite" container so the match count is announced as you type, give the input role="searchbox" semantics, and make sure the highlighted <mark> does not swallow the readable text — screen readers still read marked text, so the emphasis is purely visual. Performance is fine for a client-side catalog: filtering is a single indexOf pass over the array per keystroke and the results render with one innerHTML write. The important safety detail is escaping the query before building the highlight RegExp, which prevents both broken patterns and needless re-compilation errors. For a real backend, debounce the input by a couple hundred milliseconds so you are not firing a request per character, and guard against out-of-order responses by tracking the latest query. Rendering matches by splitting on the match, rather than injecting HTML, avoids any escaping concerns entirely when you port to a framework.

Reusing it

Swap the catalog for your data or an async endpoint (debounce the input for network calls), persist recent searches, and wire results to detail screens. Lift it out of the phone frame for a responsive web search, or keep it framed beside an expandable search field to present a full flow.