An image file naming convention is a fixed order of parts applied to every file. Four parts cover it: date as YYYY-MM-DD, subject, variant, version. Written out, a name looks like 2026-09-06-oak-chair-front-white-v3.jpg. Use lowercase letters and hyphens, with no spaces and no special characters. The date leads because it sorts correctly, and the version ends in a number because “final” always gets a sequel.
Nobody breaks a naming convention on purpose. They break it at 6pm when the file needs to go out and the rule needs a decision.
This covers the four parts, the character rules and why they exist, and the two mistakes that undo a convention that was otherwise working.
Key Takeaways
- Four parts, one order, every file: date, subject, variant, version. The order is the convention. Changing the order between files is the same as having no convention.
- Use YYYY-MM-DD. It sorts chronologically as text and it is unambiguous internationally. 06-09-2026 means two different days depending on who reads it.
- Lowercase, hyphens, no spaces. Spaces break in URLs and command lines, and mixed case creates apparent duplicates on case-insensitive systems.
- Version as v1, v2, v3, never “final”. Final has nowhere to go, and it is always followed by final-2 and then final-USE-THIS.
- Never rename a file to record approval. It breaks every existing link. Record approval elsewhere.
- A name should be readable without the folder it sits in. Files get sent, downloaded and detached from context constantly.
- Keep it under about 60 characters. Long names get truncated in interfaces and hit path limits when nested.
What are the four parts of an image file naming convention?
| Part | Format | Example | Why |
|---|---|---|---|
| Date | YYYY-MM-DD | 2026-09-06 | Sorts correctly as text, unambiguous internationally |
| Subject | lowercase-hyphenated | oak-chair | What it is, findable by search |
| Variant | lowercase-hyphenated | front-white | Which version of the subject |
| Version | v + number | v3 | Which iteration, with room to grow |
Result: 2026-09-06-oak-chair-front-white-v3.jpg
Read left to right it answers: when, what, which one, which iteration. Sorted alphabetically in any file browser it groups chronologically, then by product, then by variant, then in version order. That sorting behavior is the reason the date goes first and the reason the date format matters.
Choose the parts once for your team and do not vary the order. A convention where some files lead with the date and others lead with the product is not a convention, it is two conventions, and searching across both fails.
Why do the character rules matter?
Each character rule in a file naming convention prevents a specific, repeatable failure.
No spaces. A space becomes %20 in a URL, breaks unquoted command-line arguments, and splits filenames in scripts. If any of your images end up on a website, and they do, spaces create URLs that are harder to read and easier to break.
Lowercase only. Some systems treat Chair.jpg and chair.jpg as the same file and some treat them as two. Mixed case produces duplicates that appear and disappear depending on whose machine is looking, which is among the hardest version problems to diagnose.
Hyphens, not underscores. Both work technically. Hyphens are the convention for web URLs. Google recommends hyphens instead of underscores to separate words in a URL, because that helps people and search engines identify the concepts in it (developers.google.com, October 2026). Since product images often become URLs, hyphens are the safer default. What else Google documents for product images is sorted in image SEO for product pages. Pick one and apply it everywhere.
No special characters. Ampersands, slashes, colons, question marks, hashes and quotes all have meaning in file paths or URLs. A slash in particular is a path separator and is rejected outright.
Keep it under about 60 characters. File interfaces truncate long names in the middle, which hides the version number at the end. Deeply nested folders plus long names can also hit total path length limits on some systems.
Why does “final” always fail?
Because it describes a state that changes, and the name cannot change with it without breaking things.
The sequence is universal: chair-final.jpg, then chair-final-2.jpg, then chair-final-v2-USE-THIS.jpg, then chair-FINAL-approved-new.jpg. Each rename was reasonable at the time. Together they are four files where the newest is not identifiable by name, date or sort order.
A number solves it because a number is a fact rather than a judgment. v3 does not claim to be finished. It claims to be the third version, which is verifiable and which leaves room for v4.
Approval is a separate axis from version, and this is the part teams often get wrong. Approval belongs in a record, not in a filename, for one hard reason: renaming a file to mark it approved breaks every link that already points at it. Websites, decks, ad platforms and documents all hold the old path. Keep the name stable and record “v3 approved 2026-09-06” as the approval step of the four stages of marketing asset management. Tracking 40 generated files without a DAM covers where that record lives for a small team.
How do you handle variants without the name exploding?
Fix the order of the variant terms and use short consistent words.
An image often varies along several axes at once: angle, background, crop, format, colorway. Written freely that produces oak-chair-white-bg-front-square and oak-chair-front-square-on-white, which are the same file with two names.
Fix the axis order once. For product photography, angle then background then use is a workable default:
- 2026-09-06-oak-chair-front-white-pdp-v1.jpg
- 2026-09-06-oak-chair-angle-white-pdp-v1.jpg
- 2026-09-06-oak-chair-front-scene-social-v1.jpg
Then keep a short controlled vocabulary. Decide that it is “white” and never “white-bg” or “onwhite”. Decide that it is “front” and never “frontal” or “straight-on”. Ten agreed words cover most of a product catalog, and they should be written down next to the convention itself. This is the same discipline as the fixed constraints block in a creative brief: agree the vocabulary once, paste it every time.
Resist encoding everything. Dimensions, color profile and file format do not belong in the name when the extension and the file’s own metadata already carry them. A store such as PrestaShop builds every size from one master file, as PrestaShop product images explains, so the size never needs to be in the name.
The file name also decides how a bulk upload goes, so name the files before you start. The guides to Shopify bulk upload images and WooCommerce product image imports cover each store’s file name rules.
How do you apply this to files you already have?
Do not rename the back catalog. Start at the boundary.
Bulk renaming an existing library breaks every link pointing into it, and the links are in places you cannot audit: old decks, live web pages, ad platforms, partner emails. The cost is invisible until something 404s.
A workable sequence:
- Write the convention down in one short document, with three worked examples and the controlled vocabulary.
- Apply it to everything new, from an agreed date. The library becomes mixed, which is fine.
- Rename opportunistically, only when a file is being replaced or reworked anyway.
- Archive the old rather than renaming it, which removes ambiguity without touching live paths.
Within a couple of months the files people actually use are the new ones, and the mixed library stops mattering.
The one place to apply it immediately is anything generated in volume, because that is where a bad name multiplies fastest. A run of 200 outputs named output_1 through output_200 is unusable a week later. Set the naming pattern before the run, not after, and if the tool producing them can apply it automatically, use that.
That is the shape of the whole job. Agree the pattern on one product and write it down next to the workflow that produces the files. Then run the same workflow on the rest of the catalog and name each download by the same pattern, so the two hundredth file is named the way the first one was. A saved workflow reads the same brand rules on every run, so the last file in a batch matches the first in look. Why AI assets drift from the brand explains what that prevents.
Every result lands in one searchable library. The full workflow from the first product photo to the finished ad, in one subscription. The stills, the edits and the video cuts sit in that one library, with no export folder per tool. Batch is on every plan, and uploading your own photos starts on the Pro plan. A name that survives a download is still worth having.
FAQ
What is a file naming convention?
A fixed order of parts applied consistently to every file, so that names sort predictably and can be read without their folder. For images, four parts work: date in YYYY-MM-DD form, subject, variant and version. The consistency is what makes it useful, not the specific parts chosen.
What is the best date format for file names?
YYYY-MM-DD. It sorts chronologically when files are sorted alphabetically, and it is unambiguous internationally, unlike 06-09-2026 which reads as 6 September in most of the world and 9 June in the US. Putting the date first makes the whole library sort by date automatically.
Should I use hyphens or underscores in file names?
Either works technically, but hyphens are the better default for images because they are the web convention, and Google recommends them over underscores to separate words in URLs. Product images frequently become URLs. The important part is choosing one and applying it everywhere.
What characters should I avoid when naming files?
Avoid spaces, ampersands, slashes, colons, question marks, hashes and quotes. Each of these characters has a meaning in file paths or URLs, and a slash is a path separator that systems reject outright. Spaces become %20 in URLs, break unquoted arguments on the command line, and split filenames in scripts. Use lowercase letters, numbers and hyphens only, and keep the name under about 60 characters so the version number stays visible.
How should I number file versions?
Sequentially, as v1, v2, v3, at the end of the name. Avoid “final”, which has nowhere to go and is always followed by final-2. A number is a verifiable fact rather than a claim about completeness, and it leaves room for the next iteration.
Should I rename a file when it is approved?
No. Renaming breaks every link that already points at the file, including live web pages, decks and ad platforms, and those links cannot be reliably audited. Keep the filename stable and record approval separately, alongside whatever you use to track rights and versions.
How do I rename existing files without breaking things?
Do not bulk rename. Apply the convention to new files from an agreed date, rename opportunistically when a file is being reworked anyway, and archive superseded files rather than renaming them. The library stays mixed for a while, and the files people actually use become consistent within a couple of months.
Sources
- Google Merchant Center image requirements, the feed rules that read a product image by its URL, which is where a filename ends up (support.google.com, accessed September 2026)
- Google Search Central, URL structure best practices: hyphens instead of underscores to separate words (developers.google.com, accessed 2 October 2026)
Naming conventions drawn from standard digital asset and records management practice. Platform requirements verified from primary sources as of September 2026, and Google’s URL guidance read on 2 October 2026. Individual results vary.
