AEM Core Components: the standard component set for AEM sites

A component set for AEM, published to Maven Central

AEM Core Components is a set of standardized web content management components for Adobe Experience Manager. The stated purpose is to shorten development time and cut the maintenance cost of websites, and the mechanism is deliberately conventional: a library of components that a site uses rather than a set of patterns that each project interprets.

The scale is stated plainly. The README counts thirty components, and the component list itself is organised into two groups, template components and page authoring components. Template components cover the page itself, navigation, language navigation, breadcrumb, quick search, content AI supported search and a table of contents. Authoring components cover title, text, image, button, teaser, list, download, PDF viewer, embed, sharing, progress bar, separator, experience fragment, content fragment and content fragment list.

The delivery is Java on Maven Central, under the artifact core.wcm.components.all, with a separate core.wcm.components.core artifact for the javadoc. The badges show a Test workflow, code coverage reporting and the Maven metadata, so the artefact is treated as a released library rather than as source that a project compiles from.

Every component sits at a versioned path under /apps/core/wcm/components

The clearest thing in the repository is the naming convention. Each component lives under a path that carries its own version number, so the repository holds several generations of the same component side by side:

content/src/content/jcr_root/apps/core/wcm/components/page/v3/page
content/src/content/jcr_root/apps/core/wcm/components/navigation/v2/navigation
content/src/content/jcr_root/apps/core/wcm/components/title/v3/title
content/src/content/jcr_root/apps/core/wcm/components/image/v3/image
content/src/content/jcr_root/apps/core/wcm/components/teaser/v2/teaser
content/src/content/jcr_root/apps/core/wcm/components/list/v4/list

That layout is the versioning policy made physical. The list component is on its fourth version and the page and image components on their third, which means older generations are still available for sites that have not moved on. The policy behind it is the promise that an upgrade will not break a site, and keeping the previous versions in the tree is how that promise is kept.

For a project team this has a direct consequence. Pinning a component to a path is how you defer an upgrade for one page template without freezing the whole site, and it also means the upgrade work is a deliberate, per-component decision rather than something that arrives with a dependency bump.

Content policies decide what an author is allowed to use

The configuration model is the part that makes these components usable by people who are not developers. Content policies are defined at template level, and they determine which features the page authors are allowed to use or not.

That is a deliberate inversion of the usual approach. Instead of every component exposing every option and trusting the author to pick sensibly, the author sees a bounded set of choices for a given page type. A teaser on a landing page template might allow an image, a title and a description and nothing else, while a teaser inside an article template allows a call to action as well.

For a team with many content editors, this is where most of the maintenance saving appears. The constraint lives with the template rather than with a training document, so the editor interface cannot drift into states the front end was never designed for.

The project also documents a separate customisation route. The README points to a customisation guide that covers several patterns, from adjusting the HTML output to reusing functionality, so a team that needs different markup can extend a component rather than fork the whole set. The choice of the component path mentioned above, the versioned directory, is the other half of that story.

The Style System, BEM markup and a UI kit for Adobe XD

The theming story is built on the AEM Style System, and the markup follows BEM CSS conventions. The Style System is the mechanism that lets one component library serve sites with different visual identities, because the styling hooks are named rather than being hardcoded per project, and a design system can be pointed at them.

The design side has its own artefact. A UI kit for Adobe XD is published for the core components, so a designer can produce wireframes in a tool they already use and then style them, and the README points at a release download for the kit.

Taken together, these three pieces, the Style System, the BEM conventions and the design kit, are the answer to the question that usually kills a component library, namely what happens when the marketing team wants a different look. The answer here is that the components stay generic and the styling is a layer applied on top, and the documentation makes that separation explicit rather than leaving it to be discovered through trial and error.

The customisation patterns sit alongside this, and the README is honest that they range from adjusting HTML output to reusing functionality, which is a much larger surface than a skin.

Accessibility, semantic output and two analytics data layers

Three concerns are handled at the component level rather than left to each site.

Accessibility comes first. The components comply with the WCAG 2.1 standard, they provide ARIA labels, and they support keyboard navigation. Because the same markup is used by every site that adopts the library, this is a piece of work that a project does not have to repeat, and it is the kind of work that is usually skipped when a deadline is near.

Search engine output comes next. The HTML is described as semantic and carries schema.org microdata annotations, which is the metadata that structured data tooling reads.

Tracking is the third. There are integrations for the Adobe Client Data Layer and for the Google Data Layer, and the documentation file DATA_LAYER_INTEGRATION.md covers the tracking of all aspects of the visitor experience. Two data layers rather than one is a notable choice, because it means the same page can feed Adobe analytics and a Google tag set without a second tagging plan.

None of these are headline features on their own, and all three are the kind of detail that determines whether a shared component library justifies the switch in the first place.

JSON output for client-side rendering without giving up editing

The WebApp-Ready line in the feature list is about how a component behaves in a single page application, and it is the most interesting architectural claim in the README.

The mechanism is the streamlined JSON output, which the documentation links to the Sling Model Exporter work in the AEM development foundations. A component can render as JSON rather than as server-side HTML, which lets a JavaScript front end render the page while the content still comes from the same repository and the same components.

The catch, and the point of the paragraph, is in-context editing. The README states that the JSON output allows client-side rendering while keeping the possibility of in-context editing, and links to the SPA editor framework in the AEM documentation. That combination is the hard part of any headless setup, because the moment the page is rendered by JavaScript, the author usually loses the ability to edit the text they see on the page. Here the authoring model survives the move to a client-side render.

For a team with a design system that requires a JavaScript front end, that is the deciding feature, because the alternative is usually to give up on visual editing entirely.

Releases, tutorials and a public mailing list

The release line shows a project on a monthly cadence with patch releases inside it. Core WCM Components 2.32.6 was published on 2026-08-10, 2.32.8 on 2026-09-08 and 2.33.0 on 2026-10-05, and the last push was on 2026-10-20. The artefact names carry the reactor form, core.wcm.components.reactor with the version appended.

The documentation is unusually good for a component library. There is a component library page that shows the components in their various configurations, a component documentation section for developers and authors with details about each component, and three tutorials of different lengths: a two-day WKND tutorial for building a new site, a two-hour Summit tutorial taken from a lab at US Summit 2019, and a Gems webinar recorded in December 2018 that is described as a guided tour of the components.

Contribution runs through a contributing guide and a public mailing list, aem-core-components-dev, where ideas and questions are discussed, and there is a code of conduct in the repository. The repository root also holds BUILDING.md, CONFIGS.md, VERSIONS.md, DATA_LAYER_INTEGRATION.md, Guidelines.md and a COPYRIGHT file, and the modules all/, bundles/, config/, content/, examples/, extensions/, parent/ and testing/ show a Maven multi-module build with an example project laid out the way an AEM archetype expects, with ui.apps, ui.config and ui.content directories.

Editorial conclusion

AEM Core Components fits a team already committed to AEM as a Cloud Service, Adobe Managed Services or an on-premise deployment who wants the page and authoring components settled rather than reinvented, because the components carry content policies, a Style System, accessible markup and a data layer integration out of the box. It is the wrong choice outside AEM, where it has no meaning, and it is the wrong choice for a site whose authors need a component model Adobe did not anticipate, since the versioned paths show how narrow the built-in set is and every deviation means overriding a component. Before you adopt, read the versioning policy so you know what a future release can and cannot change under a site, check which deployment target you are on because the dispatcher layer differs, and try the WKND tutorial first, since it is the shortest path to seeing a site assembled from these components.

Frequently asked questions

Official sources

1. adobe/aem-core-wcm-components on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases