Every production company has a folder that looks something like this:
Launch_Video_FINAL.mp4Launch_Video_FINAL_2.mp4Launch_Video_FINAL_v3_approved.mp4Launch_Video_FINAL_v3_approved_NEW.mp4
Each name made sense to whoever exported it, probably late and with the client waiting. A month later someone needs the approved cut for a TV slot, and the only way to find it is to open all four and compare them by eye.
The file name is the one piece of information that goes everywhere the video goes. It sits on the drive, in the email, in the chat, on the client’s server and in the broadcaster’s upload portal.
When the name says which video this is and which version, most “which one is it?” questions answer themselves.
In short
- Name every file
CLIENT_NNN_title_vNN, with a fixed client code, a sequential number per client and a two-digit version. - Words like final, approved and new describe a status, so record approval where you track the job, not in the file name.
- Anything with its own review rounds, like a cutdown the client approves separately, gets its own number.
- Stick to lowercase letters, digits, hyphens and underscores, and write dates as YYYY-MM-DD.
- Reuse the same name in the folder, the project, every export, every message and the deliverables list.
Why every studio ends up with final_FINAL
Words like final, approved, new and fixed describe a status, and calling a file final assumes there won’t be another round. The status changes while the file name stays, so each round piles another word on top of the last one.
The other cause is that everyone has a private system. One editor starts with the date, another writes out the client’s full name, the producer renames the export before sending it, and the client saves it as “video approved ok.mp4”.
With four conventions on the same job, finding a file means asking whoever exported it.
A naming pattern you can adopt today
The whole convention fits in one line of an onboarding doc:
CLIENT_NNN_title_vNN.mp4
- CLIENT is a short code for the client, three or four capital letters, and it never changes. Acme Corporation is ACM on every job you ever do for them.
- NNN is a sequential number per client. The fourteenth video you make for Acme is 014. Don’t reuse a number when a video gets cancelled, so that ACM_014 keeps meaning one video.
- The title is one to three words in lowercase, joined by hyphens. It’s there for people scanning a folder, so
teaserorceo-interviewis plenty. - vNN is the version, with two digits. Some file browsers and servers sort v10 above v2, and the leading zero takes care of that.
Underscores separate the fields and hyphens join the words inside a field, so a person or a script can split any name back into its parts.
ACM_014 is the identity of the video. The version is a separate field that moves every round while the code stays put.
| File name | What it is |
|---|---|
ACM_014_teaser_v01.mp4 |
First cut |
ACM_014_teaser_v03.mp4 |
Third round |
ACM_014_teaser_v07.mp4 |
Approved 16:9 master |
ACM_014_teaser_v07_9x16.mp4 |
Vertical version of v07 |
ACM_014_teaser_v07_subtitled.mp4 |
v07 with subtitles |
ACM_014_teaser_v07_no-music.mp4 |
v07 without music |
ACM_015_teaser-15s_v02.mp4 |
15-second cutdown |
ACM_021_recap_2026-03-12_v01.mp4 |
Event recap, dated |
Deliverables, cutdowns and dates
Suffixes go after the version, and only when the file differs from the main cut: an aspect ratio (9x16, 1x1, 4x5), subtitled, no-music, a language code. The main cut gets no suffix. If every file carried _16x9_master_h264, nobody would read past the second underscore.
Cutdowns are where teams disagree. The rule that holds up best is that anything with its own review rounds gets its own number.
A 15-second version the client approves separately becomes ACM_015, with its own v01 and v02. If it were a suffix on ACM_014, “v02” would mean two different files depending on who you ask.
Dates go in only when they’re part of what the video is, like an event recap or a post scheduled for a specific day. Write them as YYYY-MM-DD.
That format sorts in order and reads the same in every country, while 03-12-2026 is March 12 in New York and December 3 in São Paulo. A date doesn’t replace the version number either, because two exports on the same afternoon still need two names.
Keep “final” out of the file name
Once a file is called final, the next export has to be final2, final_real or FINAL_FINAL, and from then on at least one of those names is lying.
Approval is a status, so record it where you track the job, whether that’s the review tool or the production spreadsheet. The approved file is v07 and stays v07. What changes is the note saying who approved v07 and when.
The same goes for new, fixed, ok, latest, client and people’s names, which stay true for a few days at most.
Plain version numbers also make it obvious when a job has reached v09, and that’s worth noticing early. There’s more on that in how to stop endless revision rounds.
Spaces, accents and odd characters
Lowercase letters, digits, hyphens and underscores work everywhere. This part is practical advice more than a hard rule.
- Spaces turn into %20 in links and trip up command-line scripts.
- Accented letters usually behave on the machine that created them and then sometimes get mangled after a trip through a zip file or the client’s Windows laptop, so a file called
café-reopening.mp4can arrive ascafé-reopening.mp4. - Slashes, colons, question marks and ampersands are reserved or awkward on at least one operating system.
The capitals in the client code are fine, since you choose them once and they never change.
One name, everywhere
The convention only helps if the same name shows up in every place the video lives. Pick it when the job is created and reuse it in:
- The project folder on the drive,
ACM_014_teaser. - The project file and the main sequence in Premiere or Resolve.
- Every export, with the version at the end.
- The subject line of each email and the first words of each chat message, as in “ACM_014 teaser, v03 for review”. The message that goes out with the review link carries it too.
- The deliverables list.
At the end of the job, the deliverables list uses the same names. One line per file, with the code, the approved version and the suffix, so whoever uploads to the client’s server or the broadcaster can match files without opening them:
ACM_014_teaser_v07.mp4ACM_014_teaser_v07_9x16.mp4ACM_014_teaser_v07_subtitled.mp4ACM_015_teaser-15s_v03.mp4
Some clients have their own naming system for what they receive. Ask for it before the job starts and add their reference after your code. Your folders still sort the way you expect, and every file they get carries the reference they look for.
How this works in RecReview
In RecReview, every task that belongs to a client gets a code automatically, made of the client’s code and a sequential number: MSH_001, MSH_002 and so on.
The client code is the short code you set when you register the client. Numbers count per client and are never reused, even when a task is cancelled, and a task keeps its code for good.
Versions are numbered separately. Each file uploaded to a task becomes its next version, v1, v2, v3, in the order they arrive, and you can play any two versions side by side to check what changed.
The code also helps at upload time. Pick a file whose name starts with a task’s code and the upload window selects that task for you.
With a watch folder in the Mac app you skip the window entirely. The app waits for the export to finish, uploads it, and RecReview files it as the next version of the task with that code.
It only matches names that start with one of your clients’ codes, so a file that merely looks like a code doesn’t end up on the wrong task.
When someone downloads a version, the file comes out named with the task code and title, with accents removed and underscores in place of spaces. The version control page covers the rest of how versions and comparisons work.
