Start with the questions a file name needs to answer
When a project contains several clips, captions, design files, and exports, names such as final.png or video_new.mp4 stop being useful. A good file name should answer a few questions at a glance: Which project does this belong to? What kind of asset is it? Which version or format am I looking at? The name does not need to hold the entire project brief. It only needs enough information to distinguish the file from its neighbors.
Choose a short, recognizable project label, then use it consistently across related files. A workable pattern is project_asset_description_version.ext. For example, garden-guide_caption_v02.txt identifies a working caption, while garden-guide_video-vertical_v02.mp4 identifies a video export. The exact separators matter less than using the same pattern every time. Hyphens or underscores both work; avoid switching between them within one project.
Keep descriptions brief and specific. “Intro-shot” is more helpful than “nice-clip,” and “carousel-cover” is more helpful than “image.” If a project spans several campaigns or recurring series, add a series label before the project label. Resist adding fields you rarely use: a simple system people follow is more valuable than a detailed system they abandon.
Keep original media distinct from working drafts
Source files deserve special care because they may be difficult to recreate. Store originals in a source folder and preserve their camera-generated names when those names help you match files to a device or backup. You can add context through a parent folder, such as garden-guide/source/interview, rather than renaming every original clip. If you do rename source media, keep a record of the original names so you can trace files back to a backup.
Give working files names that describe what you are editing: garden-guide_script_v03, garden-guide_cover_v02, or garden-guide_edit_v04. Use version numbers for meaningful saves, such as a new structure or a round of feedback. Avoid relying only on labels like new, newer, and final-final; they do not tell a collaborator which file came first. A simple v01, v02, v03 sequence makes that relationship visible.
A folder structure can carry information that does not need repeating in every name. For a small project, source, drafts, and exports may be enough. Within source, separate raw footage, photos, audio, and reference material if those groups become crowded. Save edited copies and project files under drafts, not alongside untouched originals. That boundary makes accidental overwrites less likely.
Name exports for the job they will do
An export name should help you select the right file without opening it. Include the project label, asset type, destination or format when relevant, and an approval state. For example, garden-guide_carousel-square_approved.png and garden-guide_video-vertical_review.mp4 distinguish a ready-to-use asset from one still awaiting feedback. Use “approved” only when someone has actually signed off; a draft that merely looks complete should retain a review label.
If you make several sizes or language variants, name the difference explicitly. Terms such as square, vertical, landscape, or a language label are easier to scan than an unexplained number. For multiple slides, use padded numbers such as slide-01 and slide-02 so files sort in the intended order. Check that each exported file contains the expected content and dimensions before moving it into the approved set; a clear name cannot compensate for an incorrect export.
Keep publication dates out of the core name unless they help identify recurring installments or scheduled releases. If you do use dates, choose one consistent format, such as YYYY-MM-DD, which sorts naturally. Do not put personal details, private feedback, or sensitive audience information into file names that might be shared with collaborators or uploaded elsewhere.
Make the system easy to maintain
Write the pattern down in a short note inside the project folder: project_asset_description_version for drafts, and project_asset_format_status for exports. Include two or three examples, not a long rulebook. When collaborators contribute files, ask them to follow the pattern for new work. It is usually more efficient to rename an occasional incoming file than to reorganize every older project at once.
At the end of a project, do a quick cleanup. Confirm that original media is backed up, move unused experiments out of the active drafts folder, and leave only the approved deliverables in exports. Keep the editable project file and any necessary supporting assets together so future revisions are possible. If a name needs a sentence of explanation, put that explanation in a project note instead.
The goal is not perfect taxonomy. It is less time spent guessing which draft to edit, which media file is original, or which export to share. Start with one project, notice where confusion still occurs, and adjust the pattern only when a new detail consistently helps you make the right choice.
