A custom field is a metadata field an organization defines itself, on top of a DAM's standard IPTC/XMP fields, to capture data no built-in standard was ever designed to hold — an internal project code, a product SKU, a usage-rights expiry date, or anything else specific to how that organization actually works.
In plain English
Standard metadata fields like Creator, Copyright Notice and Keywords cover the things almost every photo library needs, and they're part of why metadata travels cleanly between different tools. But no universal standard can anticipate every organization's own tracking needs — which internal campaign an asset belongs to, which product SKU it depicts, when a model release expires. A custom field is how a DAM lets an organization add exactly those fields itself, without waiting for a new industry standard to catch up.
The tradeoff worth understanding is portability: standard IPTC/XMP fields are embedded directly in the file itself and travel with it anywhere. Custom fields are frequently stored only in the DAM's own database, tied to that specific tool, unless the DAM specifically supports writing them into the file as extended XMP. That distinction matters enormously if a library is ever exported or migrated — a custom field that only exists in a vendor's database is exactly the kind of thing that gets silently lost in a move to a different tool.
It's worth being precise about how this differs from a controlled vocabulary: a custom field defines a new slot in the metadata record itself (a "Model Release Expiry" field, say), while a controlled vocabulary governs what values are allowed once that slot exists (a fixed list of approved project codes, rather than free text). A DAM can offer one without the other.
Why it matters in a DAM
Almost every organization eventually needs to track something standard metadata doesn't cover, and how flexible a DAM's custom fields are — and whether they actually export with the file or stay trapped in the vendor's own database — determines how much real, organization-specific structure a library can hold without fighting the tool.
Buyer’s test: during a trial, create a custom field, fill it in on a test asset, then export that asset and check whether the custom field's value survived in the exported file's metadata or only lived inside the DAM's own database. If it disappears on export, that data won't travel with the asset if you ever migrate to another tool.
Related terms
See it in action
Our metadata fidelity ranking tests how much of a library's structured metadata — standard and custom — actually survives an export and re-import round-trip, tool by tool.