AEM Assets (DAM): The Complete Guide

AEM Assets — the Digital Asset Management (DAM) side of the platform — is where an organization's images, videos, documents, and other media live, get processed, and get reused across every channel. For a backend developer it's easy to treat Assets as "just files in /content/dam," but that misses what makes it powerful: every uploaded file is automatically processed, enriched with metadata, rendered into multiple variants, and (optionally) delivered through a media-optimization network.

This guide explains how Assets actually works — the repository structure, the processing pipeline, metadata, renditions, AI-powered Smart Tags, and Dynamic Media — with the code you need to read assets from a component. A cheat sheet, best practices, and do's & don'ts close it out.

It connects to the Backend Development guide (workflows, event handlers), the Frontend Integration guide (responsive images), and the Architecture guide (the Assets tier).

How an asset is stored

Everything in AEM is content, and an asset is no exception. When you upload a file, AEM doesn't just store the bytes — it creates a structured dam:Asset node whose jcr:content holds the asset's metadata and all of its renditions:

/content/dam/mysite/hero.jpg            (dam:Asset)
└── jcr:content                          (dam:AssetContent)
    ├── metadata                         (dc:title, dc:description, dam:*, XMP)
    └── renditions
        ├── original                     ← the file you uploaded
        ├── cq5dam.thumbnail.140.100.png
        └── cq5dam.web.1280.1280.jpeg

That structure is the key to everything else: metadata lives under jcr:content/metadata, and renditions (the original plus generated variants) live under jcr:content/renditions. The rest of this guide is really about how those two subtrees get populated and used.

You read an asset in Java through the Assets API by adapting a resource to Asset:

Asset asset = resource.adaptTo(Asset.class);
String title = asset.getMetadataValueFromJcr("dc:title");
Rendition web = asset.getRendition("cq5dam.web.1280.1280.jpeg");
String mime = asset.getMimeType();

Asset processing (workflow & microservices)

The moment an asset is uploaded, AEM processes it — generating thumbnails and renditions, extracting metadata, and more. How that processing runs depends on your AEM flavor, and this is one of the biggest differences between classic AEM and the cloud.

On classic AEM 6.x / AMS, processing is driven by the DAM Update Asset workflow, which runs on the instance itself: it extracts metadata, creates the standard thumbnails and web renditions, runs Smart Tags, and so on. Heavy media work competes with the instance's other duties.

On AEM as a Cloud Service, processing is offloaded to asset microservices (Asset Compute) — cloud services that handle rendition generation and metadata extraction outside the AEM instance, so large uploads don't tax author. You control what they produce through Processing Profiles: declarative configurations that say "for this folder, also generate a 2000px WebP and a square crop." You can also run post-processing workflows for custom steps after the microservices finish.

Upload  →  [ processing ]  →  metadata extracted
                            →  renditions generated
                            →  smart tags applied
        (classic: DAM Update Asset workflow)
        (cloud:   asset microservices + Processing Profiles)

Note: On AEMaaCS, don't try to recreate heavy rendition logic in an on-instance workflow — use Processing Profiles to drive asset microservices. Reserve custom post-processing workflows for genuinely AEM-specific steps the microservices can't do.

Metadata

Metadata is the structured information about an asset — its title, description, copyright, dimensions, keywords, expiry date — and it's what makes a DAM searchable and governable rather than a folder of files. It's stored under jcr:content/metadata using standard vocabularies (Dublin Core dc:*, XMP, and AEM's dam:*) plus any custom fields you define.

Three features make metadata manageable at scale:

• Metadata schemas define the form authors see when editing an asset's metadata — which fields appear, grouped into tabs. You build them in the Metadata Schema editor and map them to fields under jcr:content/metadata.
• Metadata profiles apply default metadata automatically on upload to a folder — for example, stamping a default copyright or business unit on everything dropped into a brand folder.
• Bulk editing & search let authors update metadata across many assets at once and find assets by any indexed metadata field.

Reading metadata in code is just reading properties off the metadata node (or via the Assets API as shown above). The practical advice: agree on a metadata model early — consistent dc:title/dc:description and a few well-chosen custom fields make every downstream feature (search, governance, personalization) work.

Renditions

A rendition is an alternate version of an asset — a different size, format, or crop. The uploaded file is the original rendition; everything else is generated. AEM ships standard ones (thumbnails for the UI, a cq5dam.web.* web-optimized version), and you add your own.

Renditions exist to serve the right variant in the right place: a thumbnail in a listing, a web rendition on a page, a high-res original for download. You generate custom renditions through Processing Profiles (cloud) or the DAM Update Asset workflow (classic), and you reference them by name in components — for instance, pointing an image component at the web rendition rather than the multi-megabyte original.

// Pick a rendition by name, or fall back to the original
Rendition rendition = asset.getRendition("cq5dam.web.1280.1280.jpeg");
if (rendition == null) {
    rendition = asset.getOriginal();
}
String path = rendition.getPath();   // use in <img src> / responsive markup

For responsive delivery, you either generate a set of static renditions at fixed widths and emit a srcset, or — better for images at scale — let Dynamic Media produce sizes on demand, which is next. The Core Components' Image component already handles much of this; see the Frontend Integration guide for the markup side.

Smart Tags

Smart Tags are AI-generated tags applied automatically by Adobe Sensei during asset processing. Instead of relying on authors to tag every image by hand, Sensei analyzes the visual content and attaches tags for the objects, scenes, and concepts it recognizes — so a beach photo gets tagged "beach," "ocean," "sky" without anyone typing them.

The value is findability: a DAM with tens of thousands of assets is only useful if you can locate the right one, and Smart Tags dramatically improve search recall. They sit alongside manual tags (your curated taxonomy under /content/cq:tags), and you can search by either. For domain-specific needs, Smart Tags can be trained on your own tag vocabulary so the model recognizes brand- or industry-specific concepts. On AEMaaCS, Smart Tagging runs as part of asset microservices; on classic AEM it's a step in the DAM Update Asset workflow (and requires the Sensei integration to be enabled).

Tip: Treat Smart Tags as an augmentation of, not a replacement for, a governed manual taxonomy. Use Smart Tags for broad discoverability and manual tags for the controlled vocabulary your site navigation and personalization depend on.

Dynamic Media basics

Dynamic Media (DM) is AEM's solution for delivering rich media — images and video — optimized, on the fly, from a cloud delivery network (the technology formerly known as Scene7). Instead of pre-generating dozens of static renditions, you store one high-resolution master and DM produces any size, crop, or format on demand at the edge.

The capabilities you'll actually use:

• Image presets — named transformations (size, format, quality) applied via URL parameters, so one master serves every variant.
• Smart Crop — AI-driven responsive cropping that keeps the subject in frame across aspect ratios, configured once per asset.
• Viewers — interactive components for zoom, 360° spin, carousels, and video streaming with adaptive bitrate.
• Optimized delivery — images are served from DM's CDN, auto-negotiating format (e.g. WebP/AVIF) and size for the device.

Mechanically, when DM is enabled, an asset gains a dam:scene7File reference and is delivered through DM URLs rather than the AEM Dispatcher. The decision point is simple: for a media-heavy site that needs responsive, performant imagery and video, Dynamic Media replaces hand-managed static renditions with on-demand delivery. For a lighter site, the standard web renditions plus the Core Components Image component may be enough.

Cheat sheet

Concept	Where / how
Asset node	dam:Asset at /content/dam/...
Metadata	jcr:content/metadata (dc:*, dam:*, XMP)
Renditions	jcr:content/renditions (original + generated)
Read in Java	resource.adaptTo(Asset.class)
Get a rendition	asset.getRendition("cq5dam.web.1280.1280.jpeg")
Processing (cloud)	Asset microservices + Processing Profiles
Processing (classic)	DAM Update Asset workflow
Default metadata on upload	Metadata profile on a folder
Edit form	Metadata schema
Auto tagging	Smart Tags (Adobe Sensei)
On-demand media	Dynamic Media (presets, smart crop, viewers)

Best practices

• ✅ Agree a metadata model early; use metadata profiles to default it on upload.
• ✅ Serve web renditions or Dynamic Media to pages — never the original master.
• ✅ Drive cloud processing with Processing Profiles, not on-instance workflows.
• ✅ Use Smart Tags for discoverability and a governed manual taxonomy for structure.
• ✅ Choose Dynamic Media for media-heavy, responsive sites; static renditions for light ones.
• ✅ Read assets through the Assets API (adaptTo(Asset.class)), with null-safe rendition fallback.

Do's and Don'ts

Do

• ✅ Reference renditions by name and fall back to getOriginal() when absent.
• ✅ Configure Smart Crop once per asset for responsive imagery.
• ✅ Keep custom processing in profiles / post-processing, not the request path.

Don't

• ❌ Don't embed the multi-megabyte original in pages — use a web rendition or DM.
• ❌ Don't recreate heavy rendition logic in an on-instance workflow on AEMaaCS.
• ❌ Don't rely solely on Smart Tags for navigation-critical taxonomy.
• ❌ Don't assume a rendition exists — check, or fall back to the original.
• ❌ Don't ignore metadata governance; an untagged DAM is an unsearchable DAM.

Wrapping up

AEM Assets turns a pile of files into a governed, enriched, multi-channel media library. Remember the shape — a dam:Asset with metadata and renditions under jcr:content — and the pipeline that fills it: processing (microservices/Processing Profiles on cloud, DAM Update Asset on classic) generates renditions and extracts metadata, Smart Tags add AI discoverability, and Dynamic Media delivers optimized media on demand. Get the metadata model and rendition strategy right, and Assets scales from a handful of images to an enterprise media library without friction.

Continue with the Backend Development guide for the workflows and event handlers that drive asset processing, and the Frontend Integration guide for delivering responsive images on the page.