A useful filename answers just enough questions to prevent the wrong asset from moving forward. It should be stable, sortable and easy to read across operating systems. The folder structure and approval log can carry the context that does not belong in the name.
Choose fields that resolve real confusion
A practical sequence might be project, asset, market, channel, variant, status and version: northstar-hero-es-web-crop-approved-v03.tif. Use only fields that help people select or sort. Long names packed with comments are a sign that the workflow needs metadata or a decision log.
The US National Archives recommends consistent conventions, descriptive elements and documented version control. Its guidance also cautions against special characters that may not travel reliably between systems.US National Archives file naming guidance ↗
Control the vocabulary
Create a short list for markets, channels, crops and status. Decide whether dates use YYYY-MM-DD, whether version numbers are padded and which separator is allowed. Avoid final-final, latest and personal initials as the only signal of authority.
Treat approved as a governed status, not a descriptive adjective anyone can add. The approval register should name the version, decision owner, date, placements and any limitation. A filename points to that decision; it does not replace it.
Link sources and derivatives
Give the source asset a stable identifier that persists across crops and exports. Derivatives inherit that identifier plus their purpose. This keeps a compressed social file from becoming the accidental source of a later print version.
Useful embedded metadata can carry creator, rights and descriptive information beyond the filename. IPTC maintains a current photo metadata standard designed for exchange between systems, though teams must test whether their export and delivery tools preserve the fields they rely on.IPTC Photo Metadata Standard ↗
Test the system with a real handoff
Run the convention through three realistic cases: one asset with many crops, one campaign with markets and languages, and one correction after approval. Ask someone outside the project to locate the current master without explanation.
Publish the convention beside the working folders and include examples. If a field is routinely skipped or misunderstood, revise the system. A smaller convention people follow is safer than an elaborate taxonomy that exists only in a slide deck.
Model a campaign before setting the convention
Map the actual branches a campaign will create: master concept, markets, languages, placements, sizes, approvals and corrections. Then choose the smallest field set that distinguishes those branches. If language is already a folder boundary, repeating it in every filename may be unnecessary unless files commonly leave that folder.
Test names at their longest realistic combination and in the least capable delivery system. A technically valid name that is truncated in a portal or unreadable in review software is not operationally useful. Keep the stable asset identifier near the start if later fields are likely to disappear.
Distinguish versions, revisions and corrections
A version represents a meaningful saved state. A revision may respond to a review round. A correction after approval creates a new released version and should not overwrite the approved file. Define these terms so one team does not call a review round v12 while another sees only three substantive versions.
If an approved label contains an error, mark the old release as superseded in the register and issue a new version. Do not rename the old binary in place. Preserving the earlier checksum and decision trail makes it possible to identify where the incorrect file travelled.
Introduce the system without breaking active work
Choose a cutover date and apply the new convention to new or actively revised assets. Keep a mapping for important legacy files rather than renaming the whole archive without a plan. Bulk renaming can break placed links, code references and delivery records.
Audit a sample after two weeks. Look for invented abbreviations, skipped fields, duplicate identifiers and unofficial status words. Update the vocabulary and examples, then communicate the change. Naming is a lightweight information system and needs ownership after launch.
A practical decision table
| Field | Example | Rule |
|---|---|---|
| Asset | hero-forest | Stable human-readable identifier |
| Variant | es-web-wide | Controlled market and placement terms |
| Status/version | approved-v03 | Approval is registered elsewhere |
Release checklist
- Define the field order
- Use one separator
- Avoid spaces and unsafe symbols
- Choose sortable dates
- Pad version numbers
- Ban ambiguous final labels
- Control status terms
- Keep a stable source ID
- Document examples
- Test with a new collaborator
Common questions
Should filenames include every project detail?
No. Include selection and sorting information; keep commentary and approvals in the project record.
Can folders replace version numbers?
Folders help, but explicit versions reduce ambiguity when files are downloaded, attached or moved.