React Fragments
Learn why every component must return a single root element and how React Fragments let you group multiple elements without adding an extra DOM node.
Introduction
If you have written more than a couple of React components, you have probably hit this error: "Adjacent JSX elements must be wrapped in an enclosing tag." React components can only return one single root element from their JSX, and at first the easiest fix seems to be wrapping everything in an extra <div>. But that extra div is not free — it changes your actual HTML output, and sometimes it breaks your CSS layout (especially with Flexbox or Grid) or clutters the DOM with meaningless wrapper elements.
React Fragments solve exactly this problem. They let you group a list of children together and satisfy the single-root-element rule, without rendering any extra node to the DOM at all. This lesson covers the rule itself, why unnecessary wrapper divs are a problem, and the two ways to write a Fragment — including the one case where you cannot use the short syntax.
- Why a component must return a single root element.
- Why wrapping everything in an extra <div> can cause problems.
- How to use React.Fragment to group elements invisibly.
- The shorthand <>...</> syntax and when to prefer it.
- When you must use the explicit <Fragment key={...}> form instead.
The Single Root Element Rule
A React component's render logic (its return statement) must resolve to exactly one root React element. This is because JSX compiles down to nested function calls (React.createElement), and a JavaScript function can only return one value. If you try to return two sibling elements side by side, React (via the JSX compiler) has no way to combine them into a single return value.
function UserCard() {
return (
<h2>Jane Doe</h2>
<p>Frontend Engineer</p>
);
}
// Error: Adjacent JSX elements must be wrapped in an enclosing tag.To fix this, the two elements need a single parent wrapping them. The most obvious fix is adding a <div>, and that works — but it is not always the best choice.
function UserCard() {
return (
<div>
<h2>Jane Doe</h2>
<p>Frontend Engineer</p>
</div>
);
}The Problem With Extra Divs
Adding a wrapping <div> is harmless in small examples, but in a real application, components are nested inside other components many levels deep. If every component adds its own wrapper div just to satisfy the single-root rule, the actual rendered HTML ends up full of meaningless, empty <div> elements — sometimes called "div soup."
Broken CSS Layouts
An extra div inside a Flexbox or Grid container can break alignment, since it becomes an unexpected grid/flex item.
DOM Bloat
Unnecessary nodes make the DOM tree larger and slightly slower to query, style, and update.
Harder to Inspect
DevTools show extra wrapper elements that carry no semantic meaning, making the tree noisier to read.
Invalid HTML
Some HTML elements have strict rules about their children (e.g. <table>/<tr>), and an extra <div> can produce invalid markup.
React needs a single root for its own bookkeeping, but that root does not have to become a real DOM node. A Fragment acts as an invisible wrapper: it satisfies the rule at the JSX level, but leaves no trace in the rendered HTML.
React.Fragment
React.Fragment is a built-in component that lets you group a list of children without adding an extra node to the DOM. You use it exactly like any other wrapping element, just swapping <div> for <React.Fragment>.
import React from 'react';
function UserCard() {
return (
<React.Fragment>
<h2>Jane Doe</h2>
<p>Frontend Engineer</p>
</React.Fragment>
);
}<h2>Jane Doe</h2>
<p>Frontend Engineer</p>
<!-- No wrapping element at all — the h2 and p are direct children of whatever rendered UserCard. -->Notice that the rendered output contains only the <h2> and <p> — React.Fragment itself never appears in the DOM. It exists purely so your JSX has a single root to return.
The Short Syntax <>...</>
Because grouping elements without a wrapper is such a common need, React provides a shorthand: empty angle brackets, <>...</>. This is exactly equivalent to React.Fragment, just shorter to type and read, and it does not require importing anything.
function UserCard() {
return (
<>
<h2>Jane Doe</h2>
<p>Frontend Engineer</p>
</>
);
}No Import Needed
Unlike React.Fragment, the <>...</> shorthand requires no import statement — it is built into JSX syntax.
Less Boilerplate
It is the fastest way to group elements when you do not need to pass any props to the Fragment.
No Attributes Allowed
The shorthand cannot accept any props or attributes — not even a key.
Most Common Choice
In everyday component code, <>...</> is what you will see and use most often.
Fragments With Keys
The shorthand <>...</> syntax has one important limitation: it cannot accept any props at all, including the key prop. Normally this does not matter, but there is one situation where it does — rendering a list of Fragments with .map(), where React requires a unique key on each top-level item to track list changes efficiently.
In that case, you must fall back to the explicit React.Fragment (or just Fragment, if imported directly) so you have somewhere to put the key.
import { Fragment } from 'react';
function GlossaryList({ terms }) {
return (
<dl>
{terms.map((term) => (
<Fragment key={term.id}>
<dt>{term.word}</dt>
<dd>{term.definition}</dd>
</Fragment>
))}
</dl>
);
}<dl>
<dt>Props</dt>
<dd>Data passed from a parent component to a child.</dd>
<dt>State</dt>
<dd>Data a component manages internally and can update over time.</dd>
</dl>A <dl> element expects only <dt> and <dd> children directly inside it. Wrapping each pair in a <div> would produce invalid, non-semantic HTML. A keyed Fragment groups the pair for React's list-tracking without breaking that structure.
Common Mistakes
- Reaching for an extra <div> out of habit instead of considering a Fragment, especially when that div would affect CSS layout.
- Trying to pass a key to the shorthand <> </> syntax — it silently is not allowed, and you must use <Fragment key={...}> instead.
- Forgetting to import Fragment (or React) when using the explicit <React.Fragment> or <Fragment> form.
- Assuming a Fragment renders as an empty <React.Fragment> tag in the DOM — it renders as nothing at all.
Best Practices
- Default to the <>...</> shorthand whenever you do not need to pass a key or other prop.
- Use the explicit <Fragment key={...}> form only when rendering a keyed list of grouped elements.
- Avoid wrapping in a <div> purely to satisfy the single-root rule — reach for a Fragment first.
- Remember Fragments are invisible in the DOM; do not expect to select or style them with CSS.
- Keep semantic HTML valid by using Fragments inside elements like <table>, <dl>, or <select> that restrict their children.
Frequently Asked Questions
Does a Fragment create any real DOM element?
No. A Fragment is purely a JSX-level construct used to satisfy the single-root-element rule. Nothing corresponding to it appears in the rendered HTML.
Can I use <>...</> and pass a key to it?
No. The shorthand syntax cannot accept any props, including key. If you need a key, you must use the explicit <Fragment key={...}> form (imported from react).
Is React.Fragment the same as Fragment?
Yes. React.Fragment is accessed off the React namespace, while Fragment can be imported directly, e.g. import { Fragment } from "react". They refer to the same thing.
Why does React require a single root element at all?
JSX compiles to nested React.createElement calls, and a function can only return a single value. A Fragment gives JSX one root value to return while still allowing multiple rendered children.
Can Fragments be nested?
Yes. You can nest Fragments inside other Fragments freely; since none of them render any actual DOM node, nesting has no effect on the final HTML output.
Key Takeaways
- Every component must return a single root element from its JSX.
- Wrapping everything in an extra <div> works, but can bloat the DOM and break CSS layouts.
- React.Fragment groups children into one root without adding any real DOM node.
- The shorthand <>...</> is the same thing, written more concisely, with no import required.
- When you need a key (e.g. inside a list rendered with .map()), you must use the explicit <Fragment key={...}> form.
Summary
Fragments are a small feature with an outsized impact on how clean your rendered HTML stays. Instead of reaching for an extra <div> every time a component needs to return multiple elements, you now know to reach for <>...</> — and to fall back to the explicit <Fragment key={...}> form the moment a key is required, such as inside a mapped list.
With the single-root rule handled cleanly, you are ready to move into one of the most important topics in all of React: Hooks. The next lesson introduces what Hooks are, why they were added to React, and the rules you must follow when using them.
- You understand why components must return a single root element.
- You can explain why unnecessary wrapper divs are a problem.
- You can use both <React.Fragment> and the <>...</> shorthand.
- You know when a keyed Fragment is required instead of the shorthand.