React reconciliation is the process React uses to compare previous and next UI trees and decide what changed. It relies on stable structure and keys to preserve component identity during updates. When reconciliation is misled, React can reuse the wrong DOM nodes, which causes state bugs, flicker, or lost input.
How React reconciliation works
React reconciliation is the comparison step React uses to decide which parts of the UI tree should be updated, preserved, or removed. It is not a full redraw of the page, but a targeted decision process that tries to minimise unnecessary work while keeping the rendered output consistent with component state.
The key idea is that React compares the previous and next tree structure, then applies the smallest practical set of changes. That is why reconciliation is central to React performance and correctness: the result determines whether components keep their state, whether DOM nodes are reused, and whether the user sees a smooth update or an unexpected remount.
Why keys and stable structure matter
Reconciliation depends on predictable structure. When sibling elements keep the same relative position and stable key values, React can match old and new elements with higher confidence. That helps preserve component identity, local state, and focused inputs across renders.
When structure changes too much, or keys are missing, duplicate, or derived from unstable values such as array indexes in a changing list, React may match the wrong elements. The UI can still render, but the identity of a component can shift in ways the developer did not intend.
What React may reuse during an update
During reconciliation, React tries to reuse existing component instances and DOM nodes where the element type and position still make sense. This reuse is what allows form inputs, animation state, scroll position, and local component state to survive ordinary updates without reinitialising everything.
That reuse is also why reconciliation is sensitive to small structural choices. A change that looks harmless in code, such as reordering list items without stable keys, can cause React to preserve the wrong instance or reset the right one. The visible symptom is often subtle: flicker, stale values, or state that appears to belong to a different row or panel.
Common failure modes and their effects
The most common reconciliation problems come from unstable keys, conditional rendering that changes tree shape unexpectedly, and component reuse assumptions that do not match the data model. These issues do not usually break React itself, but they can create user-facing bugs that are hard to trace because the rendered output looks plausible.
One useful way to think about the problem is that reconciliation is both an optimisation and an identity-matching mechanism. When the identity signal is wrong, React still does what it was asked to do, but the application semantics become incorrect. That is why reconciliation bugs often appear as state leakage, lost input, or UI drift rather than obvious exceptions.
Risk and Threat Considerations
React reconciliation bugs are usually correctness and usability problems, but they can become security-relevant when they affect user input, hidden state, or component boundaries that carry permissions, selections, or workflow state. In complex apps, a mistaken reuse of UI state can mislead users, expose the wrong record, or preserve a sensitive interaction state longer than intended.
Failure mechanism: React matches the wrong element or preserves the wrong component instance because the tree shape or keys do not reliably represent the underlying data.
Impact: The application can show stale or mixed state, reset active input, trigger flicker, or make a user act on the wrong item or context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Reconciliation bugs arise from component identity and rendering architecture. |
| Recommendation — Design stable component identity and rendering paths to avoid state reuse errors. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Badly formed UI state changes can behave like invalid input to rendering logic. |
| Recommendation — Validate state transitions and list identity inputs before rendering updates. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application logic defects in UI rendering belong in secure development and testing practices. |
| Recommendation — Test list reordering, conditional rendering, and focus retention as part of application security checks. | ||
Practitioner Guidance
What to watch for: Treat reconciliation as a data-identity problem, not just a rendering detail. If UI state appears to move between rows, inputs lose focus, or updates seem inconsistent after reordering, the first thing to inspect is whether the rendered structure and keys actually describe stable identity.
Practitioner takeaway: The safest reconciliation model is one where the UI tree and the underlying data stay aligned, so React can preserve the right state for the right component.
Related resources from NHI Mgmt Group
- What breaks when authorization reconciliation is over-parallelised?
- How should security teams implement authentication in React Router apps with server-side rendering?
- Why do browser-based auth patterns break down in React Router v7?
- What do security teams get wrong about enterprise authentication for React Router apps?
