How React Reconciliation Works: Understanding Keys and the Diffing Algorithm

Mar 3, 2026

One of the most common React interview questions stumps developers who’ve been using React for years: “How does the reconciliation algorithm work?”

I remember sitting in an interview, confident after building dozens of React applications, when the interviewer asked me to explain what happens when React re-renders a list. I fumbled through an answer about virtual DOM and keys, but I couldn’t explain why keys matter or how React actually decides what to update.

This question reveals whether you understand what’s happening under React’s hood, not just how to use the API. After that interview, I dove deep into React’s internals, and now I can explain reconciliation clearly.

By the end of this article, you’ll understand:

What reconciliation is and why it matters
How React’s diffing algorithm compares trees
Why keys are critical for performance and correctness
Common anti-patterns that cause subtle bugs

Let’s start with the fundamental concept that makes React fast.

What is Reconciliation?

Reconciliation is React’s process of comparing the current DOM with the desired DOM to determine the minimal set of changes needed.

Here’s what happens every time props or state change:

Render creates a new virtual DOM tree
Diffing algorithm compares new tree vs current tree
React calculates minimal set of changes needed
Only changed parts update the real DOM

Why does this matter? Direct DOM manipulation is the slowest part of web applications. React batches updates efficiently, so you can write declarative code while React handles optimization.

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </div>
  );
}

When you click the button, React reconciles the virtual DOM and only updates the text node containing the count. The <div>, <button>, and <p> elements are reused.

The Diffing Algorithm Rules

React’s diffing algorithm makes assumptions to achieve O(n) complexity instead of O(n^3). Understanding these rules helps you write more efficient components.

Rule 1: Different Element Types = Complete Replacement

If the element type changes (e.g., <div> to <span>), React destroys the old tree and builds a new one. All state is lost.

// Before
<div><Counter /></div>

// After - Counter is destroyed and recreated
<span><Counter /></span>

This is why wrapping components in different containers can reset their state unexpectedly.

Rule 2: Same Element Type = Attribute Updates

If the element type stays the same, React updates attributes and props. State is preserved.

// Before
<div className="active" style={{color: 'red'}} />

// After - Only attributes change, DOM node reused
<div className="inactive" style={{color: 'blue'}} />

React applies style changes as individual CSS properties, not by replacing the entire style object.

Rule 3: Child Reconciliation with Keys

When reconciling children, React uses keys to identify which items changed, moved, or were added/removed. This is where you can make or break performance.

Visualizing the Process

+---------------------+
| State/Props Change |
+----------+----------+
           |
           v
+----------+----------+
| Render: New Virtual |
|      DOM Tree       |
+----------+----------+
           |
           v
+----------+----------+
| Diffing Algorithm   |
+----------+----------+
           |
           v
     +-----+-----+
     |   Compare  |
     |   Trees    |
     +-----+-----+
           |
    +------+------+
    |      |      |
    v      v      v
+---+--+ +--+---+ +------+
|Diff  | |Same  | |List  |
|Type  | |Type  | |Child |
+---+--+ +--+---+ +--+---+
    |      |         |
    v      v         v
+---+--+ +--+---+ +--+---+
|Destroy|Update| |Use   |
|&New   |Attrs | |Keys  |
+---+--+ +--+---+ +--+---+
    |      |         |
    +------+---------+
           |
           v
+----------+----------+
| Apply to Real DOM   |
+---------------------+

Why Keys Matter: The File Name Analogy

The React documentation uses a brilliant analogy: imagine files on your desktop didn’t have names. Instead, you’d refer to them by their order: the first file, the second file, and so on. You could get used to it, but once you delete a file, it would get confusing.

Keys serve as “names” for list items:

Keys give React a way to identify items between renders
Position alone isn’t enough when items can be inserted, deleted, or reordered
Keys let React track item identity across its lifetime

The Bug That Taught Me About Keys

I once spent hours debugging a contact list where the wrong person’s email appeared expanded after reversing the list. Here’s the culprit:

function ContactList() {
  const [reverse, setReverse] = useState(false);
  const displayedContacts = reverse ? [...contacts].reverse() : contacts;

  return (
    <ul>
      {displayedContacts.map((contact, i) => (
        <li key={i}>  {/* Problem: index changes when reversed */}
          <Contact contact={contact} />
        </li>
      ))}
    </ul>
  );
}

The Contact component had local state (expanded email visibility). When the list reversed, indices changed. React thought “item at position 0” was still the same component. Alice’s expanded email appeared on Taylor.

This is exactly the kind of bug that makes it into production because it only appears when users interact with lists in specific ways.

Good Keys vs Bad Keys

Good Keys

1. Database IDs

const todos = [
  { id: 'todo-1', text: 'Learn React' },
  { id: 'todo-2', text: 'Build app' },
  { id: 'todo-3', text: 'Deploy' }
];

function TodoList() {
  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

2. Unique Identifiers from API

// Real-world API data
const users = apiResponse.map(user => (
  <UserCard key={user.email} user={user} />
));

3. Composite Keys for Uniqueness

// When items might have same ID across different lists
{items.map(item => (
  <Item key={`${item.listId}-${item.id}`} item={item} />
))}

Bad Keys

1. Array Indices (Most Common Anti-Pattern)

// Causes bugs when list changes
{items.map((item, index) => (
  <Item key={index} item={item} />
))}

Why it fails:

Inserting at beginning: every item’s index changes
Deleting: items shift down
Reordering: indices completely reshuffle
State follows position, not identity

2. Random Values Generated on Render

// New key every render = no reuse
{items.map(item => (
  <Item key={Math.random()} item={item} />
))}

Why it fails:

Every render creates new keys
React can’t match previous items
All components destroyed and recreated
Performance disaster, state lost

3. Non-Unique Values

// Duplicate keys cause rendering issues
const names = ['Alice', 'Bob', 'Alice'];
{names.map(name => (
  <div key={name}>{name}</div>  // Two "Alice" keys!
))}

When Index as Key is Acceptable

Rarely, but sometimes it’s fine:

List is static (never changes)
List never reordered or filtered
Items have no interactive state
Pure display-only content

// Acceptable: Static list with no state
const navItems = ['Home', 'About', 'Contact'];
{navItems.map((item, index) => (
  <a key={index} href={`/${item.toLowerCase()}`}>{item}</a>
))}

Keys and Component State Preservation

Keys determine whether component state is preserved or reset. This is a powerful pattern once you understand it.

The Rule

Same key = same component instance = state preserved
Different key = new component instance = state reset

Example: Conditional Rendering with Keys

function EmailComposer() {
  const [draftId, setDraftId] = useState(1);
  const [showComposer, setShowComposer] = useState(true);

  return (
    <div>
      <button onClick={() => setShowComposer(!showComposer)}>
        Toggle Composer
      </button>

      {/* Same key = state preserved */}
      {showComposer && <textarea key={draftId} />}

      <button onClick={() => setDraftId(draftId + 1)}>
        New Draft
      </button>
    </div>
  );
}

Behavior:

Toggle composer: textarea state preserved (same key)
Click “New Draft”: key changes, textarea resets to empty

Practical Pattern: Forcing Component Reset

This pattern helps reset forms when switching entities:

function UserEditor({ userId }) {
  // When userId changes, key changes
  // Form component completely resets with new user data
  return (
    <UserForm key={userId} userId={userId} />
  );
}

Use cases for key-based reset:

Reset form when switching entities
Clear component state on navigation
Force re-initialization of complex components

Anti-Pattern Warning

Don’t use keys to “reset” components when you should manage state properly:

// Lazy: Using key to clear input
<input key={resetKey} />

// Better: Controlled component
<input value={inputValue} onChange={e => setInputValue(e.target.value)} />

Performance Implications

Keys affect performance in three key ways.

1. Efficient Updates

Good keys: React reuses DOM nodes, updates only what changed
Bad keys: React recreates components unnecessarily

2. Minimized DOM Operations

// Good keys: Insert at beginning
// React creates one new node, shifts references
<ul>
  <li key="new">New Item</li>
  <li key="item-1">Item 1</li>
  <li key="item-2">Item 2</li>
</ul>

// Bad keys (index): All items get new keys
// React thinks everything changed, recreates all nodes

3. Memoization Works Better

const MemoizedItem = React.memo(function Item({ data }) {
  return <div>{data.name}</div>;
});

// With good keys: MemoizedItem only re-renders when data changes
// With bad keys: MemoizedItem re-renders for every list change

Common Interview Questions and Answers

Q: What happens if you don’t provide a key?

React uses array index as default, which causes the same issues as explicitly using index.

Q: Can you use object references as keys?

Technically yes (converted to string), but not recommended:

// Objects convert to "[object Object]" - all same key
{items.map(item => <div key={item}>{item.name}</div>)}

Q: What if keys are unique but change on every render?

Components reset every render, losing state and hurting performance:

// Bad: New object reference each render
{items.map(item => (
  <Item key={{ id: item.id }} item={item} />
))}

Q: How does React use keys internally?

Keys are used by the reconciliation algorithm to match children in the new tree with children in the previous tree. They’re not passed to components as props.

Q: Do keys need to be globally unique?

No, only unique among siblings. Same key can be used in different lists:

// Fine: Keys unique within each list
<ul>
  {users.map(u => <li key={u.id}>{u.name}</li>)}
</ul>
<select>
  {products.map(p => <option key={p.id}>{p.name}</option>)}
</select>

Practical Tips and Best Practices

1. Include Keys in Your Data Model

// Good: ID comes from data
const todos = [
  { id: crypto.randomUUID(), text: 'Learn React', completed: false },
  // ...
];

// Bad: Generate keys during render
const todos = [
  { text: 'Learn React', completed: false },
  // ...
];
// Later: todos.map((todo, i) => <Todo key={i} ... />)

2. Use Short IDs for Client-Side Data

// For data that doesn't come from a database
let nextId = 0;
const addItem = (text) => {
  setItems([...items, { id: nextId++, text }]);
};

3. Fragment Keys

When returning multiple elements per list item:

import { Fragment } from 'react';

{items.map(item => (
  <Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.definition}</dd>
  </Fragment>
))}

4. React DevTools Warnings

React warns about missing or duplicate keys in development. Never ignore these warnings. They indicate real bugs.

5. Key Stability Checklist

Keys are unique among siblings
Keys don’t change between renders
Keys are derived from data, not position
Keys work correctly after insert/delete/reorder

Summary

Let me recap the key points:

Reconciliation is React’s process of efficiently updating the DOM by comparing virtual trees
Diffing algorithm makes assumptions (same type = update, different type = replace) for O(n) performance
Keys identify list items across renders, enabling correct updates when lists change
Bad keys cause bugs: state misalignment, unnecessary re-renders, lost user input
Good keys are stable and unique: typically database IDs or unique identifiers from your data

For interview preparation, make sure you can explain the “why” behind keys, not just the syntax. Be ready to discuss state preservation vs reset with keys, know when index-as-key is acceptable (rarely), and practice debugging key-related issues.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 React Preserving and Resetting State
👨‍💻 React Rendering Lists
👨‍💻 Reddit Discussion

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!