Photo file naming: keep the right version
Build a photography file naming system with stable image IDs, clear export versions, and a simple check before client delivery.
Who this guide is for
Photographers, retouchers, and studio teams handing the same images between selection, editing, and final delivery.
A client asks for the vertical portrait they chose last week. Your editing folder contains final, final-new, and final-approved. The gallery uses another number, and the retoucher has renamed the export. Finding the image now depends on somebody remembering what happened. A photography file naming system should solve that small but expensive uncertainty. Give each photograph a stable reference, add a clear purpose and revision to its exports, and keep those references through the handoff. The best starting point is a convention your team can explain in one sentence and test on one finished job.
Give the photograph an identity before a status.
Start with three separate questions: which job is this, which photograph is it, and which version am I looking at? A project code identifies the job. An image number identifies the photograph within it. An export label describes a particular output. Combining them consistently is more useful than putting every detail into a long filename.
For example, a studio might choose the project code ST042 and image number 0012. Its web export could be ST042_0012_web_v01.jpg, while a different output uses the same ST042_0012 reference. This is a sample convention, not a required industry standard. Choose labels that describe what you actually deliver, and write down what each label means.
Decide when the image reference becomes fixed. If clients have already selected image 0012, do not casually change it to 0037 during editing. When an existing job already has different camera, proof, and export names, keep a small mapping between them before making changes. Renaming files without preserving that relationship can leave a selection list pointing at a name nobody recognizes.
Use a project code rather than filling every filename with a client’s full name or contact information. Keep the information needed to identify the booking in the client record. Names should remain useful when a file leaves its original folder, without carrying unnecessary personal details into every attachment.
Separate the image number from the revision.
A revision answers “Which approved state is this?” An image number answers “Which photograph?” Do not use one to replace the other. If a client requests a change to image 0012, the next agreed export might become ST042_0012_web_v02.jpg. The picture is still 0012; the revised output has a new version.
Agree who advances that version and when. A retoucher’s working save does not automatically need to become a client-facing release. Likewise, a second export made to fix an incorrect crop should not silently replace the first approved release without the team knowing what changed. Keep a brief handoff note describing the revision and its intended recipient.
Separate working material, review exports, and ready-to-deliver files in a way the team understands. If the folder already says delivered, the filename does not need several extra forms of final. Avoid a rule that depends only on the folder name, though: a downloaded file may be separated from that folder. Its project and image reference should still make sense.
Before applying a naming preset to an entire job, test it on a small copy of the material. Check the tools you actually use for editing, sharing, and downloading. Confirm that your convention keeps names distinct and that any numbering or renaming settings do what you expect. A naming convention is a working agreement; it is not a substitute for a separate backup process.
“Keep the photograph’s identity steady. Change the label that describes the output.”
Test the handoff with one real request.
Imagine a client writes, “Please use image 0012 for the website, with the tighter crop we approved.” This is an illustrative scenario. Your system should let another team member identify the job, find the selected photograph, locate the agreed revision, and recognize the web output without relying on the original photographer’s memory.
Before delivery, compare the selected image references with the exports you intend to share. Check for missing numbers, duplicate output names, and a mix of older and newer revisions. Open a sample of the actual exported files rather than checking filenames alone. A correctly named file can still contain an unintended crop or the wrong edit.
Give the client a short instruction that matches the files they receive: “When requesting a change, please include the image reference, such as ST042_0012.” Explain which gallery or folder contains the ready-to-use version. Do not ask clients to infer approval from words such as latest, new, or final2. When several people review a commercial project, agree who consolidates their requests.
In Karavex, keep the booking context and gallery handoff connected, then use your naming agreement consistently in the files you share. Start with the next completed job rather than attempting a surprise rename of the whole archive. Keep the old-to-new mapping for any material you deliberately migrate, and check that the people receiving the files can follow it.
A file naming check before you share
- Identity: every export retains the project code and selected image reference.
- Version: output labels and revision numbers have one documented meaning and one person responsible for release.
- Handoff: selected references match the delivered files, sample exports open correctly, and the client knows how to request a change.
Make the next handoff easier to explain.
Write one naming rule, apply it to a small test export, and ask a colleague to find a specified photograph and revision. If they need you to explain which final is really final, simplify the rule. Then connect that convention to your selection and delivery instructions. Useful file naming does not make a workflow automatic. It gives the people doing the work a shared reference they can trust and verify.
Common questions
What should a photography filename include?
Use a project identifier and a stable image reference, then add the output purpose and revision where needed. For example, ST042_0012_web_v01.jpg describes one project, photograph, output, and version. Adapt the labels to your workflow.
Should I rename photos after clients choose them?
Preserve the reference clients used for selection. If names must change, keep a mapping between the original reference and the new name before editing or delivery so requests remain traceable.
Does a file naming system replace folders or backups?
No. Names identify the material, folders help organize its workflow stage, and backups protect copies independently. Test your naming convention in the tools you use and maintain a separate backup process.