Hydration is the step that bridges server-side rendering and client-side interactivity. When a server sends finished HTML to the browser, that HTML is visible but inert: it has no event handlers, no state, and no behavior. Hydration is the process by which the client JavaScript loads, matches itself to the existing HTML, and attaches the logic that makes buttons click, forms respond, and state update, all without throwing away and rebuilding the DOM the server already produced.
React’s documentation describes this directly. Its hydrateRoot function “lets you display React components inside a browser DOM node whose HTML content was previously generated by react-dom/server.” As the docs put it, “React will attach to the HTML that exists inside the domNode, and take over managing the DOM inside it.” More plainly: “Hydration turns the initial HTML snapshot from the server into a fully interactive app that runs in the browser.”
A key constraint is that the server output and the client’s first render must match. React’s documentation warns that “the server render output must match the initial render output on the client,” because “server rendering creates an illusion that the app loads faster by showing the HTML snapshot of its output,” and “suddenly showing different content breaks that illusion.” Mismatches produce errors and visible flicker.
Hydration is not free. The browser must download, parse, and execute the JavaScript for everything being hydrated, and walk the tree to wire up handlers, all before the page becomes interactive. On large pages this creates a gap where content is visible but unresponsive, sometimes called the “uncanny valley” of loading. The bigger the bundle, the longer that gap.
These costs drove a series of refinements. Partial hydration and progressive hydration hydrate only some parts of a page, or hydrate them in priority order over time. The Islands Architecture takes this further by hydrating small, independent interactive regions while leaving the rest as pure static HTML. Newer approaches such as resumability aim to avoid re-running the work entirely. All of these are responses to the same insight: server-rendered HTML is cheap to show but expensive to bring to life, so the goal is to hydrate as little as possible, as late as possible.