There are many ways to edit content in Adobe Experience Manager (AEM). 

During the last few years, while some promoted a new publishing concept called ‘headless CMS’, Adobe introduced a few new tricks in AEM to fulfil the needs of the headless community, Content Fragments and Experience Fragments. 

As they might still be seldomly used and are not self-explanatory, we will explain their differences and give you an idea of how to use them in your next project.

The rise of new content format per channel

Traditionally, most editing of content happens directly in Adobe Experience Manager (AEM) on a so-called page that relates more or less 1:1 to a page on a website: you drag and drop images from the DAM onto a page, add components and type (or copy/paste) text. 

That’s how a web page was edited 20 years ago, and still is today, right?

Riiiight. Except, you shouldn’t. Over the last few years, more and more channels appeared, such as mobile apps, social media, email newsletters and so on, that could – and should – benefit from content written for the website. 

Of course, content shall not be reused 1:1 – it has to be adapted to fit the needs of each channel: you cannot tweet a multi-page in-depth article.

Some CMS approach this by strictly separating the content from the presentation (the opposite of what traditional ‘monolithic’ CMS like older versions of AEM do) and some forget about the presentation part entirely and call it ‘headless’ CMS [link to headless article].

Adobe did not jump onto the headless bandwagon but provided means to separate content from the page-oriented management: they allowed their users to store texts and entire components in the DAM as has been possible for images for many years.

Basically, one can store two different kinds of content containers in the DAM: Content Fragments and Experience Fragments.

Experience Fragments are just a few components that belong together

Let’s explain what an Experience Fragment is first.

Imagine the website of a travel magazine. It features different variants of teasers that promote an interesting article.

These teasers all have the same elements – a title, an image, a short text and the link to the article page – although they might look completely different depending on where they are used: on the front page, in a sidebar, or even as part of an email newsletter.

Such a teaser can be stored as an Experience Fragment and used in many places throughout the website or other channels. 

Variations that serve the requirements of the different channels can be created, for example with a smaller image or less text. 

An Experience Fragment is a bit of content that belongs together and has a specific look and feel. It’s some components stored together, that can be reused anywhere on your site and in different channels.

Content Fragments are structured data

Content Fragments, on the other hand, are just what the name implies. They are fragments of content only – without the look and feel. 

Even more, Content Fragments are structured content based on a content model. 

In the AEM backend, an information architect creates a content model using the Content Model Editor by defining the different parts (attributes) of the content model, basically what type of content is allowed in the Content Fragment.

For example, an author’s bio on the website could be modeled as a Content Fragment. It contains the first name, last name, email address, a headshot and a small bio text: this is the content model definition of the Content Fragment.

Once a content fragment model has been defined, an author can create as many Content Fragments as they like: first name is Michael, last name is Grob, and so on. 

Content Fragments store data, but no information about the look and feel. 

For different use cases, variations of Content Fragments can be created that have the same structure, but different content – for example, the main text of an article (an article could be modeled as a Content Fragment too) might be longer or shorter, depending on the channel it is used in.

Content Fragments and Experience Fragments compared

Content Fragments are just data, based on a content data model that defines the structure of the data. Author’s bio, office addresses, glossary items, or even the contents of teasers can be stored as Experience Fragments (yes, you can build  Experience Fragments from a Content Fragment!).

Content Fragments can be used anywhere on the website, on a channel fed by AEM, or through the Content Services API using a headless approach.

Experience Fragments, on the other hand, are experiences of their own – content and layout. They can be any group of components of any kind, without any restriction to the structure of the fragment. They can be used to store any content that is used more than once on the (web) presence.

Content Fragment	Experience Fragment
Only data, without design. The content fragment model defines the structure of a content fragment. Used in AEM or via Content Services for a ‘headless’ approach. A content fragment can belong to an experience fragment.	Content and design. Can be a diverse group of diverse components. Experience Fragments can be used in different variants on the website and external channels. It’s not possible to create a content fragment from an experience fragment.

When to use a Content Fragment vs an Experience Fragment

It depends strongly on the use case when to choose an Experience Fragment vs a Content Fragment. 

Experience Fragments can be used freely in ad hoc situations, while Content Fragments require a bit of planning. 

Both are great instruments to manage frequently used content efficiently without the risk of copy/paste errors, and can be used to deal with many challenges in today’s marketing-driven world. 

If you’re unsure about when and how to use Content or Experience Fragments or have questions regarding your information architecture, feel free to contact us.

Michael Grob

Senior Consultant Digital Marketing