All topics
Stateintermediate

URL as State (Search Params and Routing State)

Learn when to store UI state in the URL instead of component state, and how it improves shareability and persistence.

Some UI state — the current page number, an active filter, a selected tab, a search query — represents something the user would reasonably expect to survive a page refresh or be shareable via a link. Storing that state purely in useState loses it on refresh and can't be shared, while storing it in the URL (as a path segment or query parameter) makes it durable and linkable for free.

Storing state in the URL is like writing your current progress on a bookmark you leave in a book instead of just remembering the page number in your head — anyone can pick up the book (open your link) and land exactly where you left off, and the bookmark survives even if you put the book down and pick it up again later.

Key Concepts

1
Routing libraries like React Router expose hooks such as useSearchParams that let you read and update query string parameters with an API similar to useState, so adopting URL-as-state doesn't require abandoning familiar patterns — it's a different, browser-backed storage location for the same kind of value.
useSearchParamsuseState
2
A useful mental model is distinguishing state by its 'durability and shareability' need: ephemeral UI state (a tooltip's hover state) belongs in local component state, while state that represents 'where the user is' or 'what they're looking at' (filters, pagination, active tab, selected record) is often better served by the URL, since browser back/forward, refresh, and bookmarking all work naturally with it.
3
Interviewers occasionally ask candidates to redesign a filterable list or a multi-tab page to use the URL instead of local state, checking whether they can explain the tradeoffs: URL state persists and is shareable but requires slightly more ceremony (parsing/serializing values, handling defaults) than plain useState.