Why are array indices bad keys in React?

Using array indices as keys in React causes bugs when the list order changes — items get reordered, inserted, or deleted. React uses keys to match elements between renders. When you use indices, React thinks element at position 0 is always the same item, even if the actual data shifted. This leads to incorrect DOM reuse, broken component state, stale inputs, and wasted re-renders. Always use a stable, unique identifier from your data instead.

When React re-renders a list, it needs to figure out which items are new, which were removed, and which just moved. Keys are the mechanism for this — React matches old and new elements by their key. If a key exists in both the old and new render, React reuses the existing DOM node and component instance (preserving state). If a key is new, React creates a fresh instance.

Consider a todo list where you add an item to the beginning. With index keys, every item's key shifts — what was key=0 is now key=1, what was key=1 is now key=2. React sees key=0 in both renders and assumes it's the same element, so it reuses the old DOM node and state. But the data at that position changed — so React updates the text but keeps the old component state (like checkbox checked status).

function TodoList() {
  const [todos, setTodos] = useState([
    { id: 'a', text: 'Buy milk' },
    { id: 'b', text: 'Walk dog' },
  ]);

  function addToTop() {
    setTodos([{ id: 'c', text: 'New task' }, ...todos]);
  }

  return (
    <ul>
      {/* ❌ Index keys — breaks when list order changes */}
      {todos.map((todo, index) => (
        <li key={index}>
          <input type="checkbox" /> {/* State gets mismatched! */}
          {todo.text}
        </li>
      ))}
    </ul>
  );
}

// Before addToTop:
//   key=0 → "Buy milk" (checkbox: checked ✓)
//   key=1 → "Walk dog" (checkbox: unchecked)
//
// After addToTop:
//   key=0 → "New task" (gets "Buy milk"'s checked state! 💥)
//   key=1 → "Buy milk" (gets "Walk dog"'s unchecked state! 💥)
//   key=2 → "Walk dog" (new instance, fresh state)

The checkbox state is tied to the key, not the data. When you prepend an item, all indices shift by one — React reuses the wrong DOM nodes and the checked state ends up on the wrong todo. This is the classic index-key bug.

Use a stable, unique identifier that stays with the item regardless of its position in the array. Database IDs, UUIDs, or any value that uniquely identifies the data item works. The key should be derived from the data itself, not its position.

function TodoList() {
  const [todos, setTodos] = useState([
    { id: 'a', text: 'Buy milk' },
    { id: 'b', text: 'Walk dog' },
  ]);

  function addToTop() {
    setTodos([{ id: crypto.randomUUID(), text: 'New task' }, ...todos]);
  }

  return (
    <ul>
      {/* ✅ Stable keys — correct behavior regardless of order */}
      {todos.map((todo) => (
        <li key={todo.id}>
          <input type="checkbox" />
          {todo.text}
        </li>
      ))}
    </ul>
  );
}

// Before addToTop:
//   key="a" → "Buy milk" (checkbox: checked ✓)
//   key="b" → "Walk dog" (checkbox: unchecked)
//
// After addToTop:
//   key="c" → "New task" (new instance, fresh state) ✅
//   key="a" → "Buy milk" (same instance, keeps checked state) ✅
//   key="b" → "Walk dog" (same instance, keeps unchecked state) ✅

Now React correctly identifies each item across renders. The new item gets a fresh DOM node, and existing items keep their state intact regardless of where they appear in the array.

Beyond correctness bugs, index keys also hurt performance. When you insert an item at the beginning of a list with index keys, React thinks every single item changed (because every index shifted). It re-renders every list item instead of just inserting one new node. With stable keys, React knows the existing items didn't change and only creates the one new element.

There are narrow cases where index keys won't cause problems — but they're rare enough that defaulting to stable keys is always safer. Index keys are only safe when all three conditions are true simultaneously.

In practice, this means index keys are only safe for purely static, display-only lists that will never change. The moment you add sorting, filtering, pagination, or any interactivity — you need stable keys.

This question tests your understanding of React's reconciliation algorithm and how the virtual DOM diffing works. Interviewers want to see that you can explain the specific bugs index keys cause (state mismatch, incorrect DOM reuse), understand the performance implications, know what makes a good key (stable, unique, derived from data), and can identify the rare cases where index keys are acceptable. It's a practical question — this bug shows up in production code constantly.