React Fragment: <>...</> vs <Fragment> with Examples

A React Fragment lets a component return several elements without wrapping them in an extra <div>. Write <> before the first element and </> after the last one, and React puts the elements straight into the parent, with no node of its own in the page.

function Greeting({ name }) {
    return (
        <>
            <h2 style={{ margin: 0 }}>Hello, {name}</h2>
            <p style={{ marginTop: 4 }}>You have 3 new messages.</p>
        </>
    );
}

export default function App() {
    return (
        <div>
            <Greeting name="Ada" />
            <Greeting name="Linus" />
        </div>
    );
}

Each Greeting returns a heading and a paragraph side by side. Delete the <> and </> lines and the preview shows a build error instead, because the function now tries to return two values.

Why a component needs one root

JSX is a nicer way to write function calls. <h2>Hi</h2> compiles to roughly jsx('h2', { children: 'Hi' }), one expression. A return statement can hand back one value, so two sibling tags with nothing around them are like writing return a b: the compiler stops with "Adjacent JSX elements must be wrapped in an enclosing tag".

Before fragments existed, the fix was a wrapper <div>. That works, but the div is a real element. It shows up in the DOM, it takes part in CSS layout, and some parents do not accept it as a child at all. A fragment satisfies the one root rule and then disappears.

You can see that it adds nothing. The example below renders the same two items through a fragment and through a div, then counts the direct children of each container.

import { useEffect, useRef } from 'react';

function WithFragment() {
    return (
        <>
            <span>A</span>
            <span>B</span>
        </>
    );
}

function WithDiv() {
    return (
        <div>
            <span>A</span>
            <span>B</span>
        </div>
    );
}

export default function App() {
    const first = useRef(null);
    const second = useRef(null);

    useEffect(() => {
        console.log('fragment box children:', first.current.children.length);
        console.log('div box children:', second.current.children.length);
    }, []);

    return (
        <div>
            <div ref={first}><WithFragment /></div>
            <div ref={second}><WithDiv /></div>
        </div>
    );
}

The console prints 2 for the fragment, the two spans, and 1 for the div, which wraps them. In a flex or grid container that difference decides whether the spans are laid out as items or bundled into one.

Short syntax and the Fragment component

There are two ways to write a fragment, and they compile to the same thing:

import { Fragment } from 'react';

// Short syntax, no import needed
<>
    <dt>React</dt>
    <dd>A library for building user interfaces</dd>
</>

// Long form
<Fragment>
    <dt>React</dt>
    <dd>A library for building user interfaces</dd>
</Fragment>

Use <>...</> almost everywhere. Reach for <Fragment> in one case: when the fragment needs a key. The short syntax cannot take attributes, so <key={id}> is not valid JSX. You may also see <React.Fragment> in older code; it is the same component reached through the default React import.

Keyed fragments in lists

When you render a list with map, every item needs a key so React can track it between renders (the page on lists and keys explains why). If each item is a group of elements instead of one, the key goes on the fragment, so you need the long form.

A description list is the classic case: each entry is a <dt> and a <dd>, and a <dl> should contain those directly.

import { Fragment, useState } from 'react';

const initialTerms = [
    { id: 1, term: 'Component', meaning: 'A function that returns UI.' },
    { id: 2, term: 'Prop', meaning: 'An input a parent passes to a component.' },
    { id: 3, term: 'State', meaning: 'Data a component remembers between renders.' },
];

export default function App() {
    const [terms, setTerms] = useState(initialTerms);

    return (
        <div>
            <dl>
                {terms.map((t) => (
                    <Fragment key={t.id}>
                        <dt style={{ fontWeight: 600 }}>{t.term}</dt>
                        <dd style={{ marginBottom: 8 }}>{t.meaning}</dd>
                    </Fragment>
                ))}
            </dl>
            <button onClick={() => setTerms([...terms].reverse())}>Reverse</button>
        </div>
    );
}

Click Reverse and the pairs swap places as whole units, because each pair has its own key. A wrapper <div> around each pair would also take a key, and it is valid HTML inside a dl, but it puts a third level into the markup that a fragment keeps out.

Fragments inside tables

Tables are where a stray wrapper hurts most. A <tr> expects <td> and <th> cells as its direct children. If a component that returns several cells wraps them in a <div>, the browser treats the div as one odd cell and the cells inside it stop lining up with the header.

const cell = { border: '1px solid #ccc', padding: '4px 8px' };

function CellsInDiv() {
    return (
        <div>
            <td style={cell}>$4</td>
            <td style={cell}>In stock</td>
        </div>
    );
}

function CellsInFragment() {
    return (
        <>
            <td style={cell}>$4</td>
            <td style={cell}>In stock</td>
        </>
    );
}

export default function App() {
    return (
        <table style={{ borderCollapse: 'collapse' }}>
            <thead>
                <tr>
                    <th style={cell}>Item</th>
                    <th style={cell}>Price</th>
                    <th style={cell}>Stock</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                    <td style={cell}>Pen (div)</td>
                    <CellsInDiv />
                </tr>
                <tr>
                    <td style={cell}>Pen (fragment)</td>
                    <CellsInFragment />
                </tr>
            </tbody>
        </table>
    );
}

The fragment row has its price under Price and its stock under Stock. In the div row both cells are squeezed into the Price column and the Stock column is empty. In development React also logs a warning that a <div> cannot be a child of a <tr>; the preview runs like a production build, so it skips that check, and the broken layout is what you see here. With server rendering the same mistake can also cause hydration errors, because the browser's HTML parser moves the misplaced div.

The same rule applies to <ul> and <ol>, which should contain <li> elements, and to <select>, which should contain <option> elements. Whenever a component returns pieces that belong directly inside such a parent, return a fragment.

Fragments or arrays

A component can also return an array of elements, and React renders them in order like a fragment. Each element in a returned array needs its own key, just like the output of map, because React treats the array as a list:

function Cells() {
    return [<td key="price">$4</td>, <td key="stock">In stock</td>];
}

This works, but it is noisier: commas between elements, a key on each one, and a bracket that is easy to miss when the markup grows. Use a fragment for a fixed group of elements, and keep arrays for what they are naturally, the result of mapping over data.

What a fragment cannot do

Because a fragment renders no element, it has nowhere to put a class, a style, an event handler or a ref. <Fragment className="row"> does nothing useful, and the only prop React reads from a fragment is key. When you need to style the group or listen for clicks on it, you need a real element after all, and that is fine: pick one that is valid where it sits, like a <tbody> to group rows or a <li> to hold a list item.

A fragment works anywhere an element does, including inside conditional rendering: {show && <>...</>} shows or hides the whole group at once.