Experience and Content Fragments

Two things, confusingly similar names

The distinction is genuinely simple once stated plainly, and getting it wrong causes real architectural pain:

• Experience Fragment — presentation. A group of assembled components with layout and styling. It is a piece of a page you can reuse as a page fragment.
• Content Fragment — content. Structured, channel-neutral data with no layout at all. It is a record: fields with types.

Experience Fragment = components + layout, reused as rendered experience.
Content Fragment = structured fields, rendered however the consuming channel likes.

Experience Fragments

An XF lives under /content/experience-fragments and is built with the same page editor and the same components you already use. Typical uses: site header and footer, a promotional banner reused across many pages, a campaign block shared between web and email.

• Variations — an XF can have several variations of the same experience (web, mobile, email), sharing a master.
• Building blocks — XFs can be composed from other XFs.
• Referenced on a page via the Experience Fragment component; the page renders the fragment's components inline.
• Exported — an XF can be delivered as HTML for use outside AEM, or as an offer to Adobe Target for personalisation.

The header and footer of a WKND-style template are XFs referenced from the template's structure — which is why editing the XF updates every page at once.

Content Fragments

A CF is defined by a Content Fragment Model: a schema of typed fields — text, rich text, number, date, boolean, enumeration, tags, content reference, fragment reference. Models live in /conf and must be enabled per configuration.

Model: Adventure
  title          Single line text
  description    Multi line text (rich)
  price          Number
  difficulty     Enumeration [Beginner, Intermediate, Advanced]
  primaryImage   Content reference
  itinerary      Fragment reference (multiple)

Once a model exists, authors create fragments against it. A fragment has:

• Variations — alternative renderings of the same content for different channels, e.g. a shortened summary for mobile. The master is canonical; variations override selected fields.
• Associated content — assets linked to the fragment for use wherever it appears.
• Metadata and tags — for search and filtering.

Using them

• On a page, the Content Fragment component renders selected fields of a fragment, and the Experience Fragment component embeds an XF.
• Headless delivery is where CFs earn their keep: GraphQL and OpenAPI endpoints serve them as JSON to any client. That is out of scope for this traditional-AEM track, but it is the reason the CF model exists.
• Both are translatable, and both participate in MSM — worth knowing before you scatter them across locales.

Where people go wrong

• Using a CF for a page banner. If it only ever renders as one styled block in AEM, an XF is simpler and gives authors a real editing experience.
• Using an XF for product data. Structured records forced into a layout become impossible to query, filter or deliver anywhere else.
• Modelling a CF too loosely. A model that is one big rich-text field is a page with extra steps; the value is in the typed fields.