A File-Naming System for Short Technical Videos That Survives the Next Edit

Devon — Tue, 27 Oct 2026 19:57:12 +0000

A two-minute software demo can create a surprising number of files: a screen recording, a voice track, a few graphics, an editing project, review exports, and the final version. A week later, “final.mp4” and “final-final-2.mp4” stop being funny and start costing time.

A lightweight folder and naming convention solves most of this without requiring a special app. The goal is simple: make each clip easy to find, revise, and hand off—even if you only make a few videos a month.

Start with one folder per deliverable

Give each video a short, stable project name. Avoid changing the folder name every time the title changes.

shorts-launch/
├── 00-brief/
├── 01-source/
│   ├── screen-recordings/
│   ├── camera/
│   └── audio/
├── 02-selects/
├── 03-project/
├── 04-graphics/
├── 05-exports/
│   ├── review/
│   └── approved/
└── 06-delivery/

The numbers keep folders in a useful order in file browsers. “Source” holds original recordings; “selects” contains the moments chosen for the edit; “project” holds the editable timeline; and “delivery” contains only files that are ready to share. If a folder is irrelevant to your workflow, leave it out—the structure should reduce decisions, not create filing chores.

Use names that answer four questions

A useful filename tells you the subject, version, purpose, and status at a glance. For example:

api-demo_vertical_hook-b_v03_review.mp4

api-demo identifies the topic.
vertical identifies the intended format.
hook-b distinguishes this creative variation from hook-a.
v03 marks the third meaningful edit.
review says the file is not approved for delivery.

Use lowercase letters, hyphens, and underscores consistently. Avoid spaces and vague labels such as new, latest, or final-final. Keep original camera or recorder filenames when they help preserve source identity; add a short note in the brief or a manifest rather than renaming dozens of originals by hand.

Separate takes, versions, and destinations

A take is a new recording. A version is a changed edit. A destination is a format or channel. Keeping those ideas distinct prevents filenames from turning into sentences.

For example, keep multiple recordings in the source folder as setup-take-01.mp4 and setup-take-02.mp4. If the edit changes after review, increment the export version: api-demo_vertical_v03_review.mp4, then api-demo_vertical_v04_review.mp4. If you need another aspect ratio, add a clear format label such as square or horizontal rather than calling it another version of the same file.

Do not overwrite a review export. Keeping the previous version makes it easier to compare feedback and recover a cut that was accidentally changed. Once approved, copy the chosen export to approved or delivery and mark it plainly, for example api-demo_vertical_v04_approved.mp4.

Keep a tiny project note

A short README.md in 00-brief or 06-delivery can prevent a confusing handoff. Record:

the video’s purpose and intended audience;
which source recording and take were used;
the editing application and project-file version;
the approved export filename and requested formats;
any third-party fonts, music, or graphics and their usage terms;
the date and a sentence about the latest revision.

This is especially useful when someone else has to reopen the project. An editable timeline without its source media, fonts, or instructions may not be enough to reproduce the result.

Use a three-step closeout

Before calling a clip done, do a quick file check:

Can you identify the approved file without opening it? If not, improve its name or move it into the approved folder.
Can another editor find the project and its source assets? If not, add the missing files or explain where they belong.
Can you tell what changed since the previous review? If not, update the version and the one-line project note.

A naming system is useful only if it is easy to follow. Start with one project folder, one filename pattern, and one rule: never overwrite the last review export. Add complexity only when a real project has outgrown the simple version.