How to fix React.Fragment requires a key prop when in a list in React

ReactBEGINNERMEDIUMUpdated Dec 9, 2025· 129 views

When rendering multiple Fragments in a list, you must use the explicit Fragment syntax with a key prop. The shorthand <></> syntax doesn't support keys or any props, causing errors during list rendering.

Quick fix

Fixes React.Fragment requires a key prop when in a list

import React from 'react';

const items = [{id: 1, name: 'Item 1'}, {id: 2, name: 'Item 2'}];

function List() {
  return (
    <ul>
      {items.map((item) => (
        <>
          <li>{item.name}</li>
          <li>{item.id}</li>
        </>
      ))}
    </ul>
  );
}
  1. Replace shorthand fragment syntax with explicit Fragment import
  2. Ensure the key prop uses a unique identifier
  3. Verify the import statement
  4. Review your list rendering logic
react — error
import React from 'react';
const items = [{id: 1, name: 'Item 1'}, {id: 2, name: 'Item 2'}];
function List() {
return (
<ul>
{items.map((item) => (
<>
<li>{item.name}</li>
<li>{item.id}</li>
</>
))}
</ul>
);
}
React.Fragment requires a key prop when in a list

What this error means

React requires each list item to have a unique 'key' prop to efficiently track which elements have changed, been added, or been removed. When grouping elements inside a Fragment in a list, you cannot use the shorthand `<>...</>` syntax because it doesn't support any props. Instead, you must explicitly import and use `<Fragment key={uniqueId}>` to assign a key to the fragment wrapper.

Typical symptoms

  • Console warning: 'Each child in a list should have a unique key prop'
  • List items don't update correctly when reordered or filtered
  • React.Fragment shorthand syntax fails when trying to add a key prop
  • Components re-render unexpectedly when list changes

Common causes

  1. Using the shorthand <> syntax instead of explicit <Fragment> when rendering fragments in a loop
  2. Forgetting that the shorthand fragment syntax does not accept any props, including key
  3. Not providing unique keys when fragmenting multiple elements in a list
  4. Misunderstanding React's requirement that fragments in lists must be keyed

How to fix "React.Fragment requires a key prop when in a list"

1Replace shorthand fragment syntax with explicit Fragment import

The shorthand syntax <> and </> cannot accept props. You must explicitly import Fragment from React and use the full syntax when you need to add a key prop.

Before (incorrect):

jsx
import React from 'react';

const items = [{id: 1, name: 'Item 1'}, {id: 2, name: 'Item 2'}];

function List() {
  return (
    <ul>
      {items.map((item) => (
        <>
          <li>{item.name}</li>
          <li>{item.id}</li>
        </>
      ))}
    </ul>
  );
}

After (correct):

jsx
import { Fragment } from 'react';

const items = [{id: 1, name: 'Item 1'}, {id: 2, name: 'Item 2'}];

function List() {
  return (
    <ul>
      {items.map((item) => (
        <Fragment key={item.id}>
          <li>{item.name}</li>
          <li>{item.id}</li>
        </Fragment>
      ))}
    </ul>
  );
}
2Ensure the key prop uses a unique identifier

The key should be a unique value that remains stable across re-renders. Do not use the array index as a key, as this will cause problems if the list is reordered or items are added/removed.

Good:

jsx
{items.map((item) => (
  <Fragment key={item.id}>
    {/* content */}
  </Fragment>
))}

Bad (using index):

jsx
{items.map((item, index) => (
  <Fragment key={index}>
    {/* content */}
  </Fragment>
))}
3Verify the import statement

Make sure you have imported Fragment from the 'react' package at the top of your file:

jsx
import { Fragment } from 'react';

Alternatively, you can import React and use React.Fragment:

jsx
import React from 'react';

{items.map((item) => (
  <React.Fragment key={item.id}>
    {/* content */}
  </React.Fragment>
))}
4Review your list rendering logic

If you have multiple places in your component that render lists of fragments, update each one to use the explicit Fragment syntax with appropriate key props. Check that:

- Every Fragment in a loop has a unique, stable key
- The key is derived from the data (not the array index)
- The Fragment import is present in your file
- No other props (like id, className, etc.) are being passed to the Fragment

Advanced notes

Fragments are meant to be transparent wrappers that don't appear in the DOM. The shorthand <> syntax was introduced for convenience in simple cases where no props are needed. However, when you need to assign a key (which is required for list rendering), you must use the full explicit syntax. This is a deliberate design choice by React to keep the shorthand syntax lightweight.

Common misconception: Some developers try to pass other props to fragments like className or id, expecting them to apply to the wrapper. This won't work—React.Fragment only accepts the 'key' prop (and 'children', implicitly). If you need to add attributes like className, use a div or other semantic HTML element instead of a Fragment.

Frequently asked questions

What does "React.Fragment requires a key prop when in a list" mean?
React requires each list item to have a unique 'key' prop to efficiently track which elements have changed, been added, or been removed. </> syntax because it doesn't support any props. Instead, you must explicitly import and use <Fragment key={uniqueId}> to assign a key to the fragment wrapper.
How do I fix "React.Fragment requires a key prop when in a list"?
When rendering multiple Fragments in a list, you must use the explicit Fragment syntax with a key prop. The shorthand <></> syntax doesn't support keys or any props, causing errors during list rendering.
What causes "React.Fragment requires a key prop when in a list"?
Using the shorthand <> syntax instead of explicit <Fragment> when rendering fragments in a loop Forgetting that the shorthand fragment syntax does not accept any props, including key Not providing unique keys when fragmenting multiple elements in a list
Is the "React.Fragment requires a key prop when in a list" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading