What is React hydration?

React

The short answer

Hydration is the process where React takes server-rendered HTML and "activates" it on the client side. The server sends plain HTML to the browser so the user sees content immediately. Then React runs on the client, attaches event handlers, and makes the page interactive — without rebuilding the DOM from scratch.

Why hydration exists

With client-side rendering (CSR), the browser receives an empty HTML page and waits for JavaScript to download, parse, and build the entire UI. The user sees a blank page until that is done.

With server-side rendering (SSR), the server generates the HTML and sends it to the browser. The user sees the content right away. But this HTML is static — buttons do not work, forms do not submit, nothing is interactive. It is just HTML.

Hydration bridges this gap. React looks at the server-rendered HTML, matches it with the component tree, and attaches all the event handlers and state management without throwing away the existing DOM.

How it works step by step

  1. The server runs your React components and generates HTML
  2. The browser receives this HTML and displays it immediately (the user can see content)
  3. The browser downloads the JavaScript bundle
  4. React calls hydrateRoot (or hydrate in older versions) instead of createRoot
  5. React walks through the existing DOM and attaches event listeners to the server-rendered elements
  6. The page is now fully interactive
// Client-side entry point
import { hydrateRoot } from 'react-dom/client';
import App from './App';
// Instead of createRoot (which would rebuild the DOM)
hydrateRoot(document.getElementById('root'), <App />);

Hydration vs regular rendering

With createRoot (regular rendering):

  • React creates all DOM elements from scratch
  • Any existing HTML in the container is thrown away

With hydrateRoot:

  • React reuses the existing DOM elements
  • It only attaches event handlers and sets up state
  • Much faster because no DOM creation is needed

Hydration mismatches

Here is the tricky part. React expects the server-rendered HTML to match exactly what the client would render. If they are different, you get a hydration mismatch.

// This will cause a hydration mismatch
function Greeting() {
  return (
    <p>
      Hello! The time is {new Date().toLocaleTimeString()}
    </p>
  );
}

The server renders the time at one moment, and the client renders it a few seconds later. The HTML will not match.

Common causes of mismatches:

  • Using Date.now() or Math.random() during render
  • Checking window or localStorage (they do not exist on the server)
  • Browser extensions that modify the DOM before React hydrates

How to fix mismatches:

function Greeting() {
  const [time, setTime] = useState(null);
  useEffect(() => {
    // useEffect only runs on the client
    setTime(new Date().toLocaleTimeString());
  }, []);
  return <p>Hello! {time ? `The time is ${time}` : ''}</p>;
}

Use useEffect for anything that should only run on the client. During server rendering, useEffect does not run, so the initial render matches on both server and client.

Common Pitfalls

Hydration mismatches can cause strange bugs where the UI looks correct but event handlers are attached to the wrong elements. React will warn you in development mode, but in production, it silently patches the DOM. Always fix hydration warnings — they can lead to very confusing bugs that are hard to track down.

Interview Tip

When explaining hydration, describe it as a two-step process: server sends HTML for fast initial paint, then React "wakes up" that HTML on the client. Make sure to mention hydration mismatches because that is the most common follow-up question. If you can explain why useEffect is the right place for client-only code, that shows practical experience with SSR.

Why interviewers ask this

With Next.js and other SSR frameworks becoming standard, hydration is something every React developer should understand. Interviewers want to see if you know how SSR works end to end, if you can debug hydration mismatches, and if you understand the tradeoffs between SSR and CSR. This question is especially common at companies that care about performance and SEO.

Table of Contents