Glossary

Hydration

Server-rendered HTML arrives first; hydration is what makes its buttons work.

By Roger Campos · Last updated: September 2026

TL;DR

Hydration is the step where a JavaScript framework takes HTML that was rendered on the server, rebuilds its own view of the same page in the browser, and attaches event handlers and state to the existing elements. Until it finishes the page is visible but not interactive.

Start free See the API

Free plan, no credit card. 1,000 credits a month.

How it works

How hydration works

Frameworks like Next.js, Nuxt, SvelteKit and Remix render a page to HTML on the server, so the first response already contains the text. The browser paints it straight away. Then the same component code runs in the browser: the framework walks the existing DOM, matches it to the components it would have produced, and wires up click handlers and state instead of creating the elements again. That walk is hydration.

It costs main-thread time. On a large page, hydration can be one long JavaScript task, and a tap during it waits — which is why hydration shows up in Total Blocking Time and INP. Partial hydration, islands and React Server Components are all ways of hydrating less of the page.

When it breaks

Hydration mismatches

Hydration assumes the browser renders exactly what the server did. When it doesn't — a timestamp formatted in a different time zone, Math.random() in a render, a browser extension that edited the DOM — the framework reports a mismatch. React's is Hydration failed because the server rendered HTML didn't match the client, and it may throw away the server HTML and re-render that part from scratch.

For anyone fetching the page, a hydrated site is the easy case: the content is in the HTML source, so even a plain HTTP client gets the text. What only a browser shows you is whether hydration succeeded.

URLpipe

Seeing it with URLpipe

/console loads the page in real Chrome and returns every console.error, console.warn and uncaught exception, which is where frameworks report mismatches. Run it on a production URL after a deploy to catch a mismatch your local build hid. /html gives you the DOM after hydration, to diff against the source.

Try it

Hydration, on a page you choose

Check any website for JavaScript errors

Paste a link and see the console errors, warnings and uncaught exceptions logged while the page loads in a real browser — no DevTools, no local setup.

Try it free

FAQ

Frequently asked questions

What causes a hydration error?

Anything that makes the browser's first render differ from the server's: dates and time zones, random values, reading window or localStorage during render, invalid HTML nesting, or an extension changing the DOM.

Does hydration affect Core Web Vitals?

Yes. Hydration is main-thread JavaScript, so it adds to Total Blocking Time in the lab and can delay responses to early taps, which INP measures in the field.

Can a scraper read a server-rendered page without running JavaScript?

Usually yes — the content is in the HTML source. You still need a browser for anything added after hydration, such as data loaded on the client.

Keep reading

Failed requests are never charged Rendered vs. raw HTML DOMContentLoaded Fetch a page from a residential address Find JavaScript errors on any site Client-side rendering All of glossary

See it on your own pages.

Free plan, no card. Confirm your email and your API key is live — you'll be making real requests in minutes.

Start free Email the team