File naming conventions for digital assets: a practical guide

Why it matters

Most DAM platforms search on metadata, so it is tempting to think names no longer matter. They still matter, in four places.

Outside the DAM. Files are downloaded, emailed, dropped into shared drives, attached to tickets and imported into design tools, CMSs and PIMs. Out there, the name is often the only context left. The Smithsonian's data-management guidance warns that files get moved: if they lose the folder they came from, any description held only in the folder name goes with it R4. NARA's digitization guidelines describe the same risk for files named only by sequence inside a folder. Separated from their parent directory, 001.tif from one book cannot be told apart from 001.tif from another R1.

At the system boundary. Operating systems disagree about which names are legal. Windows reserves < > : " / \ | ? *, control characters, and device names such as CON, NUL or COM1, even with an extension. Names that end with a space or a period are not supported by the Windows shell. Microsoft also tells developers not to assume case sensitivity, because some file systems treat OSCAR and oscar as different files R8. In URLs, a space or a reserved character such as #, ? or & has to be percent-encoded, so a space turns into %20 R9. The State Records Office of Western Australia advises against spaces for that reason, since they make SharePoint paths harder to read R7.

During ingest and migration. Many DAM workflows still key on the file name: duplicate checks, CSV metadata imports that match rows to assets by name, and connectors that read metadata from name segments. On the wiki, Canto can check duplicates by file name and match CSV metadata imports on file name, and Acquia DAM lists a filename-to-metadata mapping connector. A messy or non-unique naming scheme turns these helpers into a source of errors.

In public delivery. Google's image-search guidance says a short, descriptive file name (its example is my-new-black-kitten.jpg rather than IMG00023.JPG) gives "very light clues" about an image's subject. It also asks that file names be translated when images are localized R14. For assets published from a DAM or its CDN, the public name is part of the web page.

Core concepts

The Library of Congress made the underlying point in its 1995 naming recommendations, which put "unique identification rather than meaningful or expressive names" first and kept location separate from the name Unverified dated document, cited for the principle only R3. The specifics, such as 8-character components, reflect systems of that time and are obsolete.

Recommended practices

1. Decide what the name is for before deciding what goes in it

NARA advises setting the naming scheme before capture starts. Its first question is whether the name has to be read by people, by machines, or by both R1. In a DAM, the usual answer is:

• Machines identify the asset by its system ID, not its name.
• People need a name that still makes sense outside the DAM: after a download, in a shared folder, in an email.
• Integrations may need a stable, predictable name pattern, for example a product SKU or a campaign code that a PIM or CMS can match.

Write these purposes down. They decide which segments the name needs and which belong only in metadata. If no integration depends on a segment and people do not need it after download, leave it out.

2. Keep identity in the DAM ID, and meaning in metadata fields

NARA recommends that any metadata embedded in a file name, such as scan date or page number, also be recorded somewhere else, "a safety net" in case the files have to be renamed when they move between systems. It also says sequence and structure for multi-part objects belong in structural metadata, not only in the name R1. When it reviews metadata quality, NARA checks that what the name says matches what the database or file header says R1.

How to apply it:

• Map every name segment to a field in your metadata schema: project code to a project field, date to a date field, SKU to a product reference.
• Fill those fields from the name at ingest, with a parsing rule or connector, and then treat the field as the source of truth.
• Never let a business process depend only on what the name says. A name like final_approved proves nothing about approval status.

3. Restrict the character set

The archive, library and records guidance reviewed for this guide agrees:

Accents and non-Latin scripts. The Smithsonian advises ASCII alphanumerics where possible R4. One reason is Unicode normalization. The same visible character can be stored as one precomposed code point or as a base letter plus a combining mark (for example Ç versus C + combining cedilla). The two forms are canonically equivalent but are different byte strings R11. A file named on one system can therefore fail to match the "same" name on another, which breaks duplicate checks, CSV matching and links. If your organisation needs names in local scripts (Google, for example, recommends translated file names for localized images R14), pick one normalization form, NFC being the common choice, and normalize names at ingest. For storage names, keep ASCII and put the language-specific label in a title field.

4. Keep names short, and count the whole path

The NARA blog suggests 25–35 characters R2. The Smithsonian suggests 25 where possible R4. Stanford advises against long names because some software handles them badly R5. Systems have hard limits as well. Windows editions before Windows 10 version 1607 limit the full path to 260 characters (MAX_PATH), and later versions need a registry or policy change to lift it R8. On the wiki, MediaValet lists 255 characters as its limit for a file name or title. The file name is only one part of the path: a download unzipped into a deep project folder can go over the limit even when every name looks reasonable.

5. Write dates in ISO 8601 and put the most significant part first

Use YYYYMMDD or YYYY-MM-DD R2 R7 R4 R5. Ordering from year to day makes text sorting match chronological order. RFC 3339, the Internet profile of ISO 8601, notes this property for timestamps written from least to most precise R10. Put the date first only if files need to sort chronologically R4. Otherwise put the identifier or project code first so that related files group together. State which date the segment means, such as capture, creation or publication, and map it to the matching field.

6. Zero-pad sequence and version numbers

Pad numbers to the largest count you expect: 001…999, or 0001 if a shoot can produce more than 999 frames R1 R2 R4. The State Records Office of Western Australia recommends two-digit version numbers (V04, not V4) so that versions stay in numeric order R7.

For versions:

• Prefer the DAM's own versioning, which keeps one asset ID and stacks versions under it, over separate files with v01, v02 suffixes. NARA's reason for qualifiers, keeping every version under one identifier, is exactly what DAM versioning does R1.
• Where suffixes are unavoidable, such as for files that circulate outside the DAM, use v plus a zero-padded number and do not start the name with it R4.
• Avoid status words like final, final2 or final_revised. Stanford's versioning guide names these as confusing patterns R6. Status belongs in a workflow or status field.
• Make sure one number cannot mean two things. NARA points out that if 001 already marks pages, versions need a different marker R1.

7. Use a documented, segment-based pattern

A pattern made of fixed segments with fixed separators can be parsed, validated and taught. An illustrative pattern, not a standard:

<id-or-code>_<short-descriptor>_<YYYYMMDD>_<seq>[_v<NN>][_<role>].<ext>

prj0421_spring-hero_20260315_007_v02.jpg
prj0421_spring-hero_20260315_007_v02_web.jpg   (derivative, role qualifier)

Rules that make such a pattern work:

• One separator per job. For example, use underscore between segments and hyphen inside a segment. Stanford and the Smithsonian accept underscores, hyphens or camelCase, but ask for one choice applied consistently R4 R5.
• Controlled codes, not free text, for segments such as project, brand, market or asset type. Keep the list of allowed codes with your controlled vocabularies so that names and fields use the same terms. The WA guidance asks organisations to keep an approved list of abbreviations R7.
• Derivatives inherit the master name plus a role qualifier. NARA uses short role codes such as pr for a print version and t for a thumbnail, and notes that derivative names only need to lead back to the master R1.
• No repetition of what the folder or another segment already says R4.
• Not too clever. NARA warns against schemes so complex or long that people get them wrong when typing R1 R2.

8. Handle the original name explicitly at ingest

Decide, and document, what the DAM does with an incoming name:

Wiki examples of these options, with no ranking implied: Brandworkz rejects names containing characters such as /:*?<>|. MediaValet validates file names during web upload and lets users rename them in the same step. Cloudinary upload presets can name an asset with a random public ID or from the file name, and dynamic folders keep a separate display name. IntelligenceBank offers auto-sequence naming during bulk upload. Extensis Portfolio can generate keywords from the path and file name at ingest. Adobe Experience Manager Assets lists AI-assisted bulk rename. Whatever you choose, keep the original file name in a read-only field. It is often the only link back to a photographer's delivery, an agency's archive or a legacy system.

9. Generate public delivery names from metadata

For assets served to websites, the public name should be short, descriptive and translated for each market R14. Hyphens between words, as in Google's own example, keep the name readable in a URL. Do not make storage names do this job. Several DAM delivery layers build public names or links separately: Wedia lists SEO file names in its delivery module, and Brandfolder lists custom CDN links by filename. Where this is available, generate the public name from title and keyword fields so that it changes when the metadata changes. Check that a rename does not break URLs that are already published.

10. Document, validate and audit

• Publish the convention as a one-page rule with examples and the list of allowed codes. Stanford and the Smithsonian both recommend documenting it alongside the files R4 R5.
• Enforce it in software where you can: upload validation, a hot folder script, or an API pre-processor. The Smithsonian guidance points to scripting and bulk-rename tools for fixing existing sets R4.
• Audit regularly. Search for names containing spaces, non-ASCII characters, several periods or non-standard extensions, and for duplicate base names.

Common pitfalls

• Using the name as the database. Long names with ten segments, status words and free-text descriptions turn into conflicting metadata as soon as someone edits a field and not the name. Keep names thin and fields rich R1.
• Relying on name-based duplicate checks. Two different photos can share IMG_0001.JPG, and one photo can arrive under two names. Combine name checks with content-based duplicate detection or checksums. Even hashes have limits: Canto notes that MD5 values tend to change after metadata edits.
• Names that mean something only inside their folder. 001.tif in a folder called book-0001 is fine until the file leaves the folder R1 R4. Put the identifying segment in the name itself, not only in the folder.
• Case-only differences. Logo.png and logo.png may be two files on Linux or in an object store and one file on Windows or macOS defaults R8.
• Invisible character differences. Accented names copied between systems can differ in normalization form and stop matching R11.
• Renaming at migration without a crosswalk. If the new DAM renames files, embedded links, CSV imports and downstream systems that keyed on the old name stop working. Export an old-name to new-ID map and keep the original name in a field. For metadata mapping in general, see metadata schema & governance.
• Separate rules per team. Agencies, photographers and internal teams each invent a scheme. Put the convention in supplier briefs and check deliveries at ingest.
• "Final" in the name. A name cannot record approval. Use workflow status R6.

How DAM platforms support this

The wiki's solution pages document naming-related features in their Ingestion & storage, Metadata & taxonomy and Distribution & delivery sections. The pointers below are examples, not a ranking. Check each product's current documentation through its sources page.

Use the glossary for shared terms, and the comparison table for platform-level facts.