Tutorials Developer

File Naming and Folder Structure That Survives

Beginner · ~16 min

Overview

A filename is the cheapest metadata you will ever have, because it travels with the file even outside whatever system you use to manage it. Good conventions sort correctly by default, survive moving between operating systems, and can be followed from memory under deadline. Bad ones produce the familiar archive of `final_v2_FINAL_real_USE-THIS.mov`. This guide covers a convention that holds up and the specific characters and habits that cause trouble later.

What You Need

An honest look at how your current files are named
A decision about project or client codes, made once
A bulk renaming tool for fixing what already exists
Agreement from everyone who will name files, which is the hard part
A written example rather than a written rule, people copy examples
Templates or scripts that produce the convention automatically where possible

Steps

Put the date first, in year-month-day order

Writing dates as YYYYMMDD or YYYY-MM-DD means files sort chronologically by default in every file browser, every terminal, and every sync tool, with no configuration. This is the single highest-value naming decision available, and it costs nothing. Any other date order sorts incorrectly and cannot be fixed without renaming everything.

Follow with a stable project or client code

A short code, three to six characters, that never changes for the life of a project. It lets you find everything related to one job with a single search regardless of where files ended up, and it survives the project being renamed by the client, which happens more often than anyone expects.

Then a short human-readable descriptor

A few words describing what the file actually is, in a consistent style. This is the part people will read, so favour clarity over brevity, `interview-wide` beats `int-w`. Use hyphens between words consistently rather than mixing hyphens, underscores, and camel case.

End with a zero-padded version or take number

Use `v01` rather than `v1`, so version ten does not sort before version two. Zero-padding is the second-cheapest naming decision after date order, and its absence produces sorting that looks broken for reasons people struggle to identify.

Avoid the characters that break things

No spaces, which complicate scripts and URLs. No slashes, colons, asterisks, question marks, quotes, or angle brackets, several are illegal on at least one major operating system and will fail on transfer. Avoid accented characters and emoji, which survive locally and corrupt across some sync tools and archives.

Never encode status in the filename

`final`, `FINAL`, `use-this`, and `approved` are the origin of every naming horror story, because status changes and filenames do not. Status belongs in your project system, your folder structure, or your asset manager. Version numbers are fine. Judgements about which version is best are not.

Pro Tips

Write the convention as one worked example rather than a rule. People copy examples and misread rules.
Automate it wherever you can, camera naming, export presets, and templates enforce conventions better than discipline.
Fix legacy names in bulk once rather than gradually. A half-converted archive is worse than either state.
Keep folder depth shallow. Deeply nested structures hit path length limits and are painful to navigate.
The convention only works if everyone uses it. One person opting out reintroduces the search problem for everyone.

Knowledge Base

What You'll Learn

Naming is unglamorous infrastructure that determines whether an archive is searchable in five years. Below: why sort order is the real objective, and how folder structure and naming divide the work.

The Real Objective Is Sort Order and Search

Filenames do two jobs: they make files sort into a useful order automatically, and they make files findable by text search. Almost every naming rule follows from one of those.

Sort order is why dates go year-first and why version numbers are zero-padded. A default alphabetical sort, which is what every tool does unless told otherwise, produces chronological order for free if the date leads in descending significance. With any other date format, chronological order requires metadata that may not survive a copy.

Search is why the project code and descriptor matter, and why consistency matters more than the specific words chosen. A search for a project code returns everything only if the code was applied uniformly. A search for "interview" fails against files named "ivw".

Judged against those two objectives, most naming debates resolve quickly. Ornamental questions, hyphens versus underscores, matter only in that the answer is applied consistently.

Dividing Work Between Folders and Filenames

Information can live in the folder path or in the filename, and putting it in both is redundant while putting it in neither is a problem.

Folders are good for information that is stable and hierarchical: client, project, and broad category such as footage, audio, graphics, exports. Folder structure is also what people navigate visually, so it should map to how the team thinks about the work.

Filenames should carry enough that a file remains identifiable when it is out of its folder, attached to an email, dropped on a desktop, uploaded to a review platform, or recovered from a backup that lost its structure. This is the key insight: files escape their folders constantly, and a name that only makes sense in context becomes meaningless the first time that happens.

So date, project code, and descriptor belong in the name even though the folder also implies them. The duplication is deliberate insurance.

Where This Fits

This guide covers one specific part of media asset management. The wider picture, metadata schemas, naming conventions, proxies and storage tiers, governance, and avoiding vendor lock-in, is in Media Asset Management (MAM) Explained, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: Why should dates be written year first?
A: Because alphabetical sorting then produces chronological order automatically, in every tool, with no configuration. Any other date order sorts incorrectly, day-first groups every first-of-the-month together across years. It is the single cheapest and highest-value naming decision available.

Q: Should I use spaces, hyphens, or underscores?
A: Not spaces: they complicate scripts, command lines, and URLs. Hyphens or underscores both work. Pick one and apply it everywhere. Consistency matters far more than which you choose, because mixed conventions defeat search just as thoroughly as no convention.

Q: How do I fix an archive that is already badly named?
A: In one pass with a bulk renaming tool, not gradually. A half-converted archive is worse than either consistent state because you have to search both ways. Work from a copy, verify the result before deleting anything, and update the convention document at the same time.

Q: What about version numbers, how should I handle revisions?
A: Zero-padded sequential numbers such as v01, v02, v03, and nothing else. Never encode status words like final or approved into filenames, because status changes and names do not. That is precisely how you end up with final_v2_FINAL_real. Which version is current belongs in your project system.