Server-rendered React applications send fully-formed HTML to the browser on first load. That HTML is fast to display but inert — clicking a button does nothing because no JavaScript is attached yet. Hydration is the process that fixes that. The same React component tree that produced the HTML on the server is re-rendered on the client, matched against the existing DOM, and decorated with event listeners and state.
The contract hydration relies on is that the server-rendered HTML and the first client render produce identical markup. When they do not — because the component used Math.random(), checked Date.now(), read a value from localStorage, or branched on window — React emits a hydration mismatch warning and may discard the server HTML in favour of a full client render. The fix is almost always to delay the diverging behaviour until after the first render, using useEffect or a similar escape hatch.
Inside Next.js the hydration boundary also separates Server Components, which never run in the browser at all, from Client Components, which run on both sides. The boundary matters for the same reason that hydration matters: anything inside a Client Component participates in hydration, anything inside a Server Component does not. Choosing the boundary deliberately is one of the bigger architectural moves in a modern Next.js app, and one of the more common sources of bugs when the boundary is wrong.