Reference Glossary
File naming convention
A documented, agreed-upon pattern for constructing filenames so every asset in a system is named consistently and predictably.
Why it matters in a DAM
A consistent naming convention keeps files identifiable and sortable outside the DAM too — in a folder export, an email attachment, a printer's file drop — which matters because assets constantly leave the DAM's search index and travel as bare files with no metadata attached. Conventions typically fix the field order (project, date, version), the separator character, and the date format so files sort chronologically and a human can identify a file without opening it.
A worked example
Common mistake
Conventions get documented but not enforced at ingestion, so within months half the library follows the rule and half still carries camera-default or freelancer-supplied filenames, defeating the point.
A file naming convention is the rule set behind every filename in a DAM: what fields it includes, in what order, separated by what character, in what date format. Its value is easy to underestimate because a good DAM’s search makes filenames feel unimportant — but the moment an asset is exported, emailed, or handed to a print vendor, the filename is the only metadata that travels with it.
Digital preservation guidance from library and archives institutions converges on a small set of practical rules: use only letters, digits, hyphens, and underscores; avoid spaces and special characters that behave inconsistently across operating systems; use ISO 8601 date format (YYYYMMDD) so files sort chronologically; and zero-pad sequence numbers so “page2” doesn’t sort after “page100.” These aren’t arbitrary style preferences — each rule solves a specific, observed failure mode in real file systems.
The gap between having a convention and having consistent filenames is enforcement, not documentation. A style guide that lives in a PDF nobody reads at upload time produces the same messy library as having no convention at all — which is why the more durable version of this concept, controlled file naming, builds the rule into the system itself rather than relying on contributors to remember it.
Frequently asked
Why does a naming convention matter even with good DAM search?
Inside the DAM, search works because assets carry structured metadata—tags, keywords, custom fields—so the filename itself barely matters for retrieval. But that metadata usually doesn't survive the trip out: the moment a file is exported, attached to an email, dropped into a shared folder, or handed to a print vendor, most systems strip or ignore the embedded context. At that point the filename is the only label left, so it needs to carry enough information—project, date, version—to identify the asset on its own.
What rules does digital preservation guidance recommend for filenames?
Guidance from bodies like the U.S. National Archives (NARA) and the Library of Congress converges on a few rules: use only letters, digits, hyphens, and underscores—no spaces, ampersands, apostrophes, or parentheses, since those characters break scripts and URLs. Dates should follow ISO 8601 (YYYYMMDD) so they sort chronologically. Sequence numbers need zero-padding for correct numeric sort. NARA also caps total file-path length around 255 characters and discourages multiple periods before the extension.
Why does zero-padding sequence numbers matter?
Most file systems and DAM asset lists sort filenames as text, character by character, not by numeric value. Without zero-padding, 'page2' sorts after 'page10' and 'page100' because '1' comes before '2' in that first-character comparison, scrambling the intended sequence. Padding every number to a fixed width—say 001, 002, …010, …100—so all sequence numbers share the same digit count keeps the list in true numeric order. The padding width should be chosen to cover the largest expected count in the series.
What's the gap between documenting a convention and having it followed?
A documented convention is just text—a wiki page, PDF, or style guide describing rules. Whether it's actually followed depends on separate factors: whether new contributors ever read it, whether freelancers and vendors receive it before delivering files, and whether anyone checks incoming assets against it. Without a review step or automated check at ingest, documentation and practice drift apart fast. A style guide nobody consults while naming a file produces the same disorganized library as never having written one.
What typically happens to a naming convention that's only documented, not enforced?
Within months, a split emerges: part of the library follows the rule, while the rest still carries camera-default names (IMG_1234.jpg, DSC00123.CR2), freelancer-supplied filenames, or names inherited from stock downloads. New contributors who never saw the guide, or saw it once and forgot the specifics, keep adding to the inconsistent portion. Because renaming after the fact risks breaking existing links, embeds, and cross-references to those assets, the split tends to persist rather than self-correct, leaving the library permanently mixed.
What's the more durable alternative to a documented-only convention?
Controlled file naming shifts the rule from a document to the system itself: the DAM either auto-generates the filename from structured fields (project code, date, sequence) at upload, or validates incoming filenames against a defined pattern and rejects or renames anything that doesn't match. Because the system enforces the pattern automatically, the convention no longer depends on every contributor remembering or reading a style guide—it holds regardless of who's uploading, freelancer or staff, making it far more durable than documentation alone.
Sources
- Digital preservation best practice recommends filenames use only letters, digits, hyphens and underscores (no spaces or special characters), ISO 8601 date format, and zero-padded sequence numbers so files sort and open correctly. checked 2026-08-07 — Penn State University Libraries — Personal Digital Archiving guide