A server-rendered React component renders a <div> inside a <p>. The markup uses no dates, randomness or browser APIs, yet hydration still reports a mismatch. What causes it?

## The mismatch that has nothing to do with your data Most hydration mismatches come from the server and client computing different values. This one is different: both renders produce the *identical* React tree. The divergence happens in between, in the browser's HTML parser. ## HTML has a content model, and the parser enforces it HTML is not a generic tree format. Elements declare what they may contain, and the parsing algorithm repairs violations rather than erroring. The rule that bites here: `<p>` accepts only phrasing content — text, `<span>`, `<a>`, `<em>` and friends. A `<div>` is flow content. When the parser is inside an open `<p>` and meets a `<div>` start tag, it implicitly closes the paragraph first. So the server sends: ```html <p>Intro <div>Details</div></p> ``` and the browser builds: ```html <p>Intro </p><div>Details</div><p></p> ``` The div is now a *sibling* of the paragraph, and there is a stray empty paragraph from the orphaned closing tag. No warning is shown to the user; this is defined recovery behaviour, and it happens before any JavaScript runs. ## Why that breaks hydration specifically Hydration adopts existing DOM. React walks the nodes the parser produced, matching each against the element it is currently rendering. It renders `<p>` and looks for the paragraph's first child to match its `<div>` — and finds the paragraph closed, with the div outside. The structures do not line up, so React reports a hydration error and falls back to client-rendering that subtree, discarding the server HTML there. Client-only rendering hides this bug entirely, which is why it so often appears the day a team turns on SSR: `createRoot` builds the DOM by calling `appendChild`, and the DOM API does *not* enforce the content model. A div appended into a paragraph programmatically simply stays there. Only the parser rewrites markup, and the parser only sees the server's HTML string. ## The family of parser rewrites to know - **`<div>` (or any flow content) inside `<p>`** — paragraph implicitly closed. - **Table foster parenting.** Text or a `<div>` placed directly inside `<table>` outside a cell is moved *before* the table in the DOM. - **Implicit `<tbody>`.** Writing `<table><tr>…</tr></table>` gets a `<tbody>` inserted around the rows, so React's tree and the DOM differ by one level. - **Nested `<a>`** — an anchor inside an anchor is unwound; the inner one becomes a sibling. - **Nested `<form>`** — the inner form element is dropped. - **`<li>` outside a list, `<td>` outside a row** — relocated or discarded. All of them share the signature: a mismatch whose diff shows a *structural* difference — an element in the wrong place or an unexpected extra node — rather than differing text. ## Diagnosing it fast React validates DOM nesting in development and warns when the element renders, with a message naming both elements — that a `<div>` cannot appear as a descendant of `<p>`. That warning usually fires *before* the hydration error and identifies the component, so read the earliest message in the console, not the loudest one. A second confirmation: inspect the element in DevTools and compare the live DOM with the HTML in the network response's document — if they differ structurally before hydration, the parser did it, not your code. An especially sneaky variant is indirect nesting: a `<Card>` renders a `<div>` at its root and someone drops `<Card>` inside a `<p>` several components away. The illegal nesting is invisible in either file on its own, which is why the development warning that names the ancestor chain is worth reading carefully. ## Fixing it Fix the markup, not the symptom. Use a `<div>` or a `<span>` wrapper as the content model allows: if the child is inline, `<span>` is legal inside `<p>`; if the child is a block, the parent should not have been a paragraph. Do **not** reach for `suppressHydrationWarning` here — it silences reports about an element's own text and attributes, it does not make an illegally nested tree hydrate, and the underlying DOM would still be shaped differently from what your components describe, which quietly breaks styling and refs too. The general lesson worth stating in an interview: with SSR, invalid HTML stops being a validator nag and becomes a correctness bug, because the server's string and the client's tree must agree exactly.