What Is Hydration in React?
Learn what hydration is in React, how it makes server-rendered HTML interactive, and what causes mismatches.
Expected Interview Answer
Hydration is the process where React attaches event listeners and internal state to server-rendered HTML that is already sitting in the browser, turning static markup into a fully interactive application without re-creating the DOM from scratch.
When a server-rendered page loads, the browser first displays plain HTML that was generated on the server, so users see content quickly, but nothing responds to clicks yet because no JavaScript event handlers are wired up. Hydration runs React’s rendering logic against that existing DOM, walking the tree and reusing the already-present elements while attaching the listeners, refs, and component state React needs, rather than tearing everything down and rebuilding it. For this to work, the component tree React renders during hydration must produce markup that matches what the server sent; a mismatch — for example content that differs between server and client, like a timestamp or random ID rendered differently — causes a hydration mismatch warning and can force React to discard and re-render the affected subtree client-side. Because hydration still has to run the full component tree’s JavaScript before the page becomes interactive, large apps can suffer from a period where content is visible but not yet clickable, which frameworks address with techniques like streaming and selective/progressive hydration.
- Lets users see meaningful content immediately from server-rendered HTML
- Avoids the cost of re-creating DOM nodes that already exist
- Bridges server rendering with full client-side interactivity
- Enables progressive/streaming hydration to prioritize visible content first
AI Mentor Explanation
Hydration is like a stadium being fully set up overnight — pitch marked, seats arranged, scoreboard displaying yesterday’s final score — so fans arriving early already see a complete-looking venue. But the actual match staff, umpires, and scoring system have not started work yet, so nothing is truly live. Hydration is the moment the ground staff and officials come on duty and connect themselves to that already-built setup, making it a genuinely live, responsive match rather than rebuilding the stadium from an empty field. If the overnight setup does not match what officials expect, they have to redo parts of it on the spot.
Step-by-Step Explanation
Step 1
Server renders HTML
The server runs the component tree and sends fully formed, static HTML to the browser.
Step 2
Browser paints static markup
Users see content immediately, but no JavaScript event handlers are attached yet.
Step 3
React runs hydration
React walks the same component tree client-side, reusing existing DOM nodes and attaching listeners/state instead of recreating them.
Step 4
Page becomes interactive
Once hydration completes, clicks, inputs, and state updates work as they would in a fully client-rendered app.
What Interviewer Expects
- Clear distinction between server-rendered static HTML and a fully hydrated, interactive page
- Understanding that hydration reuses existing DOM nodes rather than rebuilding them
- Awareness of hydration mismatch errors and their common causes
- Knowledge of mitigations like streaming or selective/progressive hydration for large apps
Common Mistakes
- Confusing hydration with a full client-side re-render from an empty page
- Not knowing what causes hydration mismatches (e.g. Date.now(), random IDs, browser-only APIs)
- Assuming server-rendered content is already interactive before hydration finishes
- Ignoring the “uncanny valley” period where content is visible but not yet clickable
Best Answer (HR Friendly)
“Hydration is what happens after a server sends a ready-made webpage to your browser. You can see the content right away, but it is not clickable yet because the JavaScript has not attached itself. Hydration is React coming in and wiring up all the interactivity to that existing page instead of rebuilding it, so it becomes a fully working app.”
Code Example
// Server: render to static HTML string
import { renderToString } from 'react-dom/server'
const html = renderToString(<App />) // sent to the browser immediately
// Client: attach React to the existing server-rendered DOM
import { hydrateRoot } from 'react-dom/client'
hydrateRoot(document.getElementById('root'), <App />)
// React reuses the existing DOM nodes and attaches event listeners
// instead of recreating the tree from scratchFollow-up Questions
- What causes a hydration mismatch, and how does React handle one when it happens?
- How does streaming SSR change when hydration can begin?
- What is selective or progressive hydration and why does it help large pages?
- How does hydration differ between renderToString and renderToPipeableStream?
MCQ Practice
1. What does hydration primarily do?
Hydration reuses the existing server-rendered DOM and wires up interactivity rather than rebuilding it.
2. What commonly causes a hydration mismatch?
If server-rendered markup differs from what the client would render, React flags a mismatch.
3. Before hydration completes, what is true of a server-rendered page?
Static HTML paints immediately, but event handlers are not attached until hydration finishes.
Flash Cards
What is hydration? — Attaching React event listeners/state to existing server-rendered HTML.
What causes a hydration mismatch? — Server and client rendering producing different markup, e.g. from timestamps or random values.
What is the interactivity gap called? — The period where content is visible but not yet clickable, before hydration finishes.
What helps large-app hydration? — Streaming SSR and selective/progressive hydration.