Naming conventions for footage: what actually survives three years
The parts of a filename that survive are the parts a machine generated: an ISO date, the camera original reel and clip number, and a project code you fixed once. The parts that decay are every hand-typed description, because your abbreviations change and the shoot gets re-labelled halfway through.
Published September 10, 2026 · Field notes
Go back to a drive from three years ago and it is obvious which parts of a filename still work. The dates still work. The reel numbers still work. The words you typed - "final", "good takes", "harbour_v2_REAL" - do not, because you were describing the file relative to a context that no longer exists.
The rule: only machine-generated fields survive
A field survives if it was produced by something that cannot change its mind. Three qualify:
- ISO date, YYYY-MM-DD. Sorts correctly as text, unambiguous internationally, written by the camera.
- Project or client code. Short, fixed once, never re-worded. ACME26 rather than acme-rebrand-final.
- Camera original identifier. A001_C012, DJI_0431, GX010097. This is the file's identity - it maps back to the card and preserves shooting order.
Which gives a name like:
2026-04-18_ACME26_A001_C012.MOVUnderscores between fields, hyphens inside a field, no spaces, no punctuation beyond those two. Spaces survive fine on modern systems but break command-line tools, some render farm software and a surprising amount of web tooling, and you will eventually pass this through one of them.
Why descriptive names decay
Three failures, all of which show up on any drive older than a year:
- Vocabulary drift. The same subject gets called harbour, harbor, docks and waterfront by the same person across one project. No single search string finds them all.
- Relative words. "Final", "new", "v2", "old" describe a moment, not a file. There are two finals on every drive.
- Truncation. Long descriptive names get abbreviated inconsistently once the path gets deep, and the abbreviations are what you have to search for later.
The deeper problem is that a filename holds one description, and the reason you go looking for a clip is rarely the reason you described it. You named it drone_harbour and you are now looking for a wide establishing shot at golden hour. Same file, wrong handle - the multi-axis problem from the folder structure that stops working at about 500 clips, in a different guise.
Where to put the description instead
Three places, in increasing order of durability:
- A shoot-notes text file in the shoot folder. Plain text, indexed by every desktop search tool, readable in thirty years, costs five minutes on the day.
- Embedded metadata fields. XMP keywords and description written with ExifTool or Bridge travel with the file across drives and applications. Do not use them for camera originals if your workflow checksums them.
- An index that reads the picture. No typing, no vocabulary to agree with your future self, and it produces the axis a filename cannot: what the shot actually looks like.
Renaming safely, if you must
Batch renaming is where libraries get broken. Two rules make it survivable:
- Never rename inside camera-originals. That folder is immutable. Everything else is derived and can be rebuilt.
- Check for project references first. If an NLE project still points at those paths, renaming breaks the link, and name-based relinking fails once the name has changed. Finish or archive the project first.
A dry run matters more than the tool. ExifTool, Adobe Bridge and A Better Finder Rename all preview the result; run the preview over the whole set and read it before committing, because the failure case is silent and affects every file at once.
What this means if you index your library
Reelary keys entries by path and modification time, so renaming a file makes it look like a new file: the old entry becomes a missing item and the renamed file is re-indexed on the next pass. Nothing is lost, but it is work, and it is another reason to settle naming before indexing rather than after.
When a naming convention is still the right answer.
If your clips are distinguished by something invisible - which contract they fall under, which of two identical-looking takes was approved, which version went to the client - put it in the filename or in metadata, because no index that reads pixels will ever recover it. Visual search replaces the descriptive half of naming, not the administrative half.
Questions people ask about this
What is a good naming convention for video files?
Use only machine-generated parts: an ISO date (YYYY-MM-DD), a short fixed project code, and the camera original reel and clip identifier, joined by underscores with no spaces. Add a description only on files you created - selects and exports - never on camera originals.
Why do descriptive filenames stop helping over time?
Because the words drift. The same shoot becomes "harbour", "harbor", "rotterdam" and "client-final" across three months, so no single search string matches all of it. Machine-generated fields do not drift, which is why they are still useful three years later.
Is it safe to batch-rename footage after a project is finished?
Only outside your camera-originals folder, and only if no project file still references those paths. Renaming a file that an NLE project points at breaks the link, and a relink by name will fail once the name has changed. Rename derivatives freely; leave originals alone.