Metadata is the whole product: how to describe assets so they can be found

Nobody has ever chosen a platform because of its metadata editor. Everybody who has abandoned a library abandoned it because search returned nothing useful, which is the same thing one step later.

Short answer: metadata is not a feature of digital asset management, it is the product. Storage is commodity, delivery is commodity, and the only durable difference between an asset library and an expensive drive is whether the fields on an asset are consistent enough to query. Get three things right: keep the metadata the file already carries, add a small number of controlled fields, and make them queryable. Platforms like Cloudinary expose that last part directly through structured metadata with typed, validated fields rather than free text.

Schematic exploded view of an image asset with its metadata layers drawn as labelled plates behind it: exif, iptc, xmp and custom fields, one plate amber and empty

The three layers you inherit for free

Before you design anything, know what is already in the file. Most teams discover they have been sitting on half a catalogue.

Exif. Written by the camera. Capture time, device, exposure, sometimes GPS. Reliable, machine-generated, useless for meaning but excellent for deduplication and for reconstructing which shoot a file came from.
IPTC. The photography industry's descriptive standard: creator, credit line, description, keywords, rights, location. The IPTC Photo Metadata specification is the closest thing to a lingua franca for editorial and stock imagery, and it is what agencies deliver against.
XMP. Adobe's container format, now the usual carrier for the other two plus anything custom. XMP embeds structured data in the file itself, which means it survives the file leaving your system.

That last property is the one worth pausing on. Embedded metadata is portable across platforms in a way that your DAM's internal fields are not. If you ever migrate, or send an asset to a partner, embedded fields go with it and database fields do not. Audit what you have with ExifTool before you write a single custom field, because you may be about to rebuild something you already own.

Free text is not metadata

Here is the failure that produces dead search. A team adds a keywords field, lets everyone type into it, and two years later the library contains hero, Hero, hero image, hero-shot, HERO_2024 and heroimage, none of which match each other.

Free text captures effort. It does not capture agreement. Search only works when two people describing the same thing produce the same string, and that only happens if the system refuses the alternatives.

Two field lists side by side: free text with ragged inconsistent entries, and controlled with the same rows snapped to a fixed vocabulary and validation ticks

So the practical rule is: every field a human fills in by hand is either a controlled list or a mistake waiting to age. Dates, numbers and booleans are fine because their types constrain them. Anything categorical needs a fixed set of allowed values, enforced at entry.

You do not need to invent those sets from nothing. Dublin Core terms give you a small, stable core of descriptive properties that has survived thirty years of everyone else's schemas. The Getty vocabularies give you controlled terms for materials, places, subjects and agents if your assets are cultural or editorial. For anything that will be published on the web, map your public-facing fields to Schema.org ImageObject so the description you already wrote does double duty.

How many fields should a DAM actually have?

Fewer than you want, and the number is closer to twelve than to sixty.

Every field is a tax charged at ingest. A schema with forty required fields produces one of two outcomes: nobody uploads anything, or everybody fills the fields with garbage to get past the form. Both destroy search more thoroughly than having no fields at all, because garbage is indistinguishable from data.

A workable starting schema:

What it is. Asset type, subject or product reference, one controlled category.
Who made it. Creator, agency or source, capture date. Mostly auto-filled from Exif and IPTC.
What is allowed. Approval state, licence type, usage rights, expiry date. This is the set people skip and then regret.
Where it belongs. Campaign, market, channel. Multi-value, controlled.
What it looks like. Orientation, dominant colour, whether there is space for text. Increasingly derivable automatically rather than typed.

That last point is genuinely changing the economics. Automated analysis can now produce tags, detect subjects and describe content on ingest, which turns the description problem from a human bottleneck into a review step. Cloudinary handles this through its analysis capabilities, and comparable automated tagging exists in most serious platforms now. Treat the output as a draft, not as truth: automated tags are excellent at what is in the frame and poor at why it matters.

Horizontal bar chart titled time to find, with four retrieval methods, the longest bar amber and the shortest cyan

Metadata for callers that are not people

The reason to take this seriously in 2026 rather than 2016 is that the thing querying your library increasingly is not a person.

A designer with a half-described library still finds the file, because they remember the shoot and they can recognise the image on sight. A script cannot recognise anything. It reads fields, and if the fields are empty it either fails or invents something. That is the entire argument in what an AI agent needs from your DAM, and it is why the same schema that felt like bureaucracy five years ago is now the interface.

The same holds for any programmatic consumer. A build pipeline pulling assets by query, a storefront selecting a packshot by product code, a headless setup where every asset is fetched over an API: all of them read fields and none of them can ask a colleague.

Start smaller than you think

Pick five fields. Make three of them controlled lists. Backfill them for your top two hundred assets, not for everything. Run real queries against that subset for a month, and only then extend the schema, because you will discover that two of your five fields were the wrong ones and one field you never considered is the one everybody searches on.

Schema design is iterative and the first version is always wrong. What matters is that it is small enough to be wrong cheaply.

For the wider context this sits in, start with what digital asset management actually is. If you are still choosing a platform, judge the metadata model before the feature list: how the platforms differ on who they are for is largely a story about how opinionated their schemas are.