---
title: Reuse a fragment (embed)
category: Reuse content across pages
order: 2
status: published
summary: Reuse a page or entity as a shared fragment with embeds so updates propagate everywhere.
estimatedTime: 5 min
keywords: embed embedded page fragment entity reuse
---

In this how-to, you'll learn how to reuse a fragment across many pages using embeds.

Docs reference:

- [Reuse content across pages](https://docs.reactbricks.com/common-tasks/reuse-content-across-pages/)
- [Embed Pages](https://docs.reactbricks.com/bricks/embed)

## What an embed is

An embed lets you render one page inside another page.

This is useful when you want a single source of truth for a shared fragment.

For example:

- a site-wide CTA
- a newsletter signup section
- a reusable promo block
- a product teaser reused in many pages

When the original embedded page changes, every page embedding it reflects that change.

That is the key difference from stories.

With stories, you reuse a brick configuration.
With embeds, you reuse live content.

## Store reusable fragments as entities

Reusable fragments are usually not normal routed pages.

For that reason, it is a good idea to create a dedicated entity page type.

```tsx
import { types } from 'react-bricks/rsc'

const pageTypes: types.IPageType[] = [
  {
    name: 'fragment',
    pluralName: 'Fragments',
    defaultStatus: types.PageStatus.Published,
    getDefaultContent: () => [],
    isEntity: true,
    allowedBlockTypes: ['call-to-action', 'newsletter-subscribe'],
  },
]

export default pageTypes
```

With `isEntity: true`, these reusable fragments appear under the `Entities` tab instead of the main pages list.

That keeps them separate from normal website pages.

## Use the default embed brick

React Bricks includes a default embed brick unless it is disabled through `enableDefaultEmbedBrick`.

That default brick lets editors embed any page of any type.

This is the fastest option when:

- you are fine with a generic embed experience
- editors are allowed to reuse many kinds of pages
- you do not need to restrict the selection to a single page type

## Create a custom embed brick

If you want a stricter editor experience, create a custom embed brick that only allows a specific page type.

For example, you may want editors to embed only `fragment` entities.

```tsx
import { types } from 'react-bricks/rsc'

const FragmentEmbed: types.Brick = () => null

FragmentEmbed.schema = {
  name: 'fragment-embed',
  label: 'Embed Fragment',
  category: 'Embed',
  sideEditProps: [
    {
      name: types.EmbedProp,
      label: 'Embed a fragment',
      type: types.SideEditPropType.Relationship,
      relationshipOptions: {
        references: 'fragment',
        multiple: false,
      },
      helperText: 'Choose a fragment, then save to view it.',
    },
  ],
}

export default FragmentEmbed
```

There are 2 important parts here:

- `name: types.EmbedProp` tells React Bricks this brick performs an embed
- `relationshipOptions.references` limits the selectable pages to the `fragment` page type

## A typical editor workflow

In a common setup, the workflow looks like this:

1. A developer creates a `fragment` entity page type.
2. Editors create reusable entities such as `summer-cta` or `newsletter-signup`.
3. Editors insert the embed brick into normal pages.
4. They choose which fragment to embed.

From that point on, the fragment has one source of truth.

If the editor updates the original entity, every page using that embed gets the new version.

## When embed is the right choice

Use an embed when:

- the same content must stay synchronized across many pages
- editors should update one source instead of many copies
- the reused content is bigger than a single brick preset

This is especially useful for fragments that can change over time, such as campaigns or cross-site CTAs.

## When not to use embed

For global layout elements like the header and footer, a dedicated `<PageViewer>` in the app layout is usually better than embedding them on every page.

That is the pattern used in the starter projects, and it avoids treating header and footer as page-level embeds everywhere.

We'll cover that in the next guide:
[Manage header and footer](/how-tos/reuse-content-across-pages/manage-header-and-footer)