Content Fragments

Learn what Content Fragments are, how they differ from regular page content, and why they're the foundation of headless AEM delivery.

Last reviewed: December 2024

·AEM 6.4+AEM 6.5AEM as a Cloud Service
✅
Quick Understanding: A Content Fragment is structured content that is separated from its presentation. Think of it as a database record stored in AEM — it has fields (like a title, body, and image) but no built-in HTML styling. The same fragment can be displayed on a web page, a mobile app, and a kiosk — each with different styling.

🔍 What Is It?

A Content Fragment is:

  • →Structured content stored in AEM's DAM (Digital Asset Manager) under /content/dam
  • →Defined by a Content Fragment Model (like a database schema)
  • →Presentation-independent — the content exists separately from how it looks
  • →Deliverable via GraphQL (headless) or page components (traditional)
  • →Supports variations — one fragment can have a "Web" variation and a "Mobile" variation with different text

Content Fragments are different from regular page content because they're created by content editors in a dedicated editor (not the page editor), and they can be reused across multiple pages and channels.

🎯 Why Do We Need It?

The Problem: Modern businesses publish content on websites, mobile apps, smartwatches, digital signage, and voice assistants. Writing the same content separately for each channel is expensive and leads to inconsistency.

The Solution: Content Fragments let you write content once and deliver it everywhere:

  • →The marketing team writes an article once in AEM
  • →The web team displays it on the website using a component
  • →The mobile team fetches it via GraphQL API
  • →The digital signage team pulls the title and image for their display

This is the core of headless and hybrid AEM architectures.

🏗️ What Happens in Real Projects?

Real Project Scenarios:

Scenario 1: Product Catalog

A retailer creates a "Product" Content Fragment Model with fields: name, SKU, description, price, images, specifications. The product team fills in fragments for 10,000 products. The website, mobile app, and in-store kiosks all consume the same data.

Scenario 2: News Articles

A media company creates an "Article" model with: headline, body, author, publishDate, category, featuredImage. Journalists write articles as fragments. The website renders them as pages; the mobile app fetches them via GraphQL.

Scenario 3: Shared Component Content

A global company has a "Disclaimer" fragment used on 500 pages. When the legal team updates the disclaimer fragment, all 500 pages reflect the change automatically.

⚙️ How It Works

Step 1: Create a Content Fragment Model

In AEM's Tools → Assets → Content Fragment Models, you define the schema:

  • →What fields does this type of content have?
  • →What type is each field? (text, number, date, content reference, etc.)
  • →Which fields are required?

Step 2: Create Content Fragments

Authors go to Assets → Files → (your DAM folder) and create fragments based on the model. They fill in the fields in a clean, focused editor.

Step 3: Use the Fragment

*Option A: In a page component*

Use the Content Fragment Core Component to drop a fragment onto a page. The component renders the fragment's fields using HTL.

*Option B: Via GraphQL (headless)*

Query the fragment using AEM's GraphQL API:

{
  articleByPath(_path: "/content/dam/articles/my-article") {
    item {
      title
      body { html }
      author { name }
    }
  }
}

Variations:

A fragment can have multiple variations. The "Master" variation is the default. You can create "Social Media" or "Short Summary" variations with different text lengths.

💻 Example

Content Fragment Model and GraphQL Query — Creating a "News Article" Content Fragment Model and querying it via GraphQL.

json
// News Article Content Fragment Model
// Defined in AEM Tools → Assets → Content Fragment Models

{
  "modelTitle": "News Article",
  "fields": [
    {
      "fieldLabel": "Headline",
      "name": "headline",
      "type": "text-single",
      "required": true,
      "maxLength": 100
    },
    {
      "fieldLabel": "Body",
      "name": "body",
      "type": "text-multi",
      "renderAs": "richtext"
    },
    {
      "fieldLabel": "Author",
      "name": "author",
      "type": "fragment-reference",
      "modelPath": "/conf/mysite/settings/dam/cfm/models/author"
    },
    {
      "fieldLabel": "Publish Date",
      "name": "publishDate",
      "type": "date-time"
    },
    {
      "fieldLabel": "Featured Image",
      "name": "featuredImage",
      "type": "content-reference",
      "mimeTypes": ["image/*"]
    },
    {
      "fieldLabel": "Category",
      "name": "category",
      "type": "enumeration",
      "options": ["Technology", "Business", "Sports", "Health"]
    }
  ]
}

🤔 Common Confusions

❓ What is the difference between Content Fragments and Experience Fragments?

Content Fragments are pure content — no HTML, no styling. Experience Fragments are complete HTML experiences — they include the content AND the layout/styling. Use Content Fragments for headless delivery and structured data. Use Experience Fragments for reusable page sections that need consistent styling.

❓ Where are Content Fragments stored?

In the DAM (Digital Asset Manager) under /content/dam, not under /content/sites. This is intentional — fragments are assets, not pages. They're managed in the Assets console, not the Sites console.

❓ Can I use Content Fragments without going headless?

Yes. The Content Fragment Core Component lets you drop a fragment onto a regular AEM page. This is called "hybrid" delivery — you get the benefits of structured, reusable content while still using AEM's page editor.

❓ What is a Content Fragment Model vs a Content Fragment?

The Model is the schema (like a database table definition). The Fragment is the actual content (like a database row). You create one Model and then many Fragments based on that Model.

🚨 Common Production Issues

GraphQL query returns null

the Content Fragment Model's GraphQL API might not be enabled. Enable it in Tools → Assets → Content Fragment Models → Model Properties.

Fragment changes not reflecting on pages

the page component is caching the fragment data. Check if the Sling Model or component has caching that needs to be invalidated.

Fragment editor shows wrong fields

the model was updated but existing fragments weren't migrated. Fragments store data based on the model at creation time.

Performance issues with large fragment lists

GraphQL queries without proper pagination can return thousands of results. Always use limit and offset in queries.

Fragment references broken after DAM reorganization

moving fragments in the DAM breaks references. Use Find & Replace References before moving.

Published page shows incomplete fragment data

referenced fragments, referenced assets, or the Content Fragment Model itself were not published with the parent fragment.

Model change breaks a headless app

field names or data types changed without coordinating API consumers and persisted queries.

Authoring becomes confusing

models contain too many optional fields, unclear labels, or channel-specific fields that should have been variations or separate models.

✅ Best Practices

Design your Content Fragment Models carefully upfront

changing models after content is created is painful.

Use Fragment References to create relationships between fragments (e.g., Article references Author).

Create separate DAM folder structures for fragments and media assets to keep things organized.

Enable versioning for Content Fragments in production so you can roll back content changes.

Use variations for channel-specific content (web, mobile, social) rather than creating separate fragments.

For headless delivery, always use persisted queries instead of ad-hoc GraphQL queries

they're faster and cacheable.

Govern Content Fragment Models like API schemas

review field names, required fields, references, and backward compatibility before changes.

Use DAM folder permissions and clear naming conventions so authors do not mix fragments, media assets, and archived content.

Include fragments, models, persisted queries, and referenced media in release and publishing checklists.

🏛️ Architect's Note

Senior Architect's Perspective

Content Fragments are the foundation of modern AEM architecture. If you're building a new AEM project in 2024, your content model should be designed around fragments.

Architecture Decision: Should you use Content Fragments or page-based content? Rule of thumb:

  • →Content that's reused across channels → Content Fragments
  • →Content that's specific to one page → Page content
  • →Content created by non-technical editors → Content Fragments (cleaner editor experience)

For AEM as a Cloud Service: Content Fragments + GraphQL is the recommended pattern for headless delivery. Adobe is investing heavily in this area — Content Fragment Models, the GraphQL API, and the Content Fragment Editor all have significant improvements in AEMaaCS.

💬 Frequently Asked Questions

How many Content Fragment Models should a project have?

Start with the minimum needed to represent your content types. A typical project might have 5–15 models. Avoid creating a model for every slight variation — use variations within a fragment instead.

Can Content Fragments be translated?

Yes. AEM's translation workflow supports Content Fragments. You can send fragments to a translation service and receive translated versions as separate language copies in the DAM.

What is a "persisted query" in GraphQL?

A persisted query is a GraphQL query that's saved on the AEM server and accessed via a simple GET URL. This is preferred over ad-hoc queries because: it's cacheable by the Dispatcher and CDN, it's faster, and it prevents clients from running arbitrary expensive queries.

Can I nest Content Fragments inside other Content Fragments?

Yes, using Fragment References. An Article fragment can reference an Author fragment, which can reference a Company fragment. This creates a content graph. Be careful with deep nesting — it can cause performance issues in GraphQL queries.

🎯 Key Takeaways

1Content Fragments = structured content without presentation
2Defined by a Model (schema) → filled in as Fragments (data)
3Stored in DAM (/content/dam), not in Sites (/content/sites)
4Deliverable via GraphQL (headless) or page components (traditional)
5Variations allow channel-specific content from one fragment
6Foundation of headless and omnichannel AEM architectures

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these AEM references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages

SplashRide AEM learning path

Browse the full AEM topic collection and learning order on SplashRide.

AEM Interview Prep

Practice AEM interview questions and scenario-based answers.

AEM Developer Career Path

This AEM developer career path explains how to become an AEM developer through JCR, Sling, HTL, client libraries, Dispatcher, Cloud Service delivery, project depth, and interview-ready enterprise implementation skills.

Drupal Developer Career Path

A practical route through Drupal content modeling, site building, theming, modules, configuration management, APIs, performance, deployment discipline, and interview preparation.

Experience Fragments

Learn what Experience Fragments are, how they differ from Content Fragments, and when to use them in real AEM projects.

AEM GraphQL

Learn how AEM's GraphQL API enables headless content delivery from Content Fragments to any channel or application.