Where Should State Live in a React Application?

Direct answer: put state next to the components that read and write it. Lift it only when siblings must share it. Reach for Context, a reducer, a server-state library, or an external store only when that placement fails.

This guide is the placement decision. For the full tool comparison, see State Management. For derived-state bugs, see Anti-Patterns.

When to use this

• You are about to add Context, Redux, or Zustand “just in case”
• Prop drilling feels annoying but you are not sure it is a real problem
• Server data and UI chrome are mixed in one store

When not to use this

• You already know the data is remote and need caching, retries, and dedupe: start with a server-state library
• You need SSR rendering strategy advice: see SSR, SSG, ISR, or CSR

Practical example

function SearchPage({ products }) {
  // local: only this page cares about the query
  const [query, setQuery] = React.useState('')
  const visible = products.filter((p) =>
    p.name.toLowerCase().includes(query.toLowerCase())
  )

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ul>
        {visible.map((p) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </>
  )
}

query stays local. products come from the parent or a fetch cache. Do not copy products into state unless the user can edit them independently.

Decision guide

Common mistakes

• Syncing props into state with useEffect when you could derive during render
• Putting server responses in a global client store by default
• Creating Context for every prop that travels two levels

Checklist

• Can one component own this value?
• If shared, what is the nearest parent that already knows both sides?
• Is this a server mirror? Prefer a fetch/cache library.
• Will many unrelated screens update this often? Only then consider a store.

Related

• State Management
• Context vs Zustand
• State Management Anti-Patterns
• Stop Unnecessary Re-renders

Final recommendation

Default to local state. Lift narrowly. Treat server data as server state. Add Context or a store when sharing or update frequency proves local state is too awkward, not before.