A file naming convention is a fixed order of parts applied to every file. For images, four parts cover it: date as YYYY-MM-DD, subject, variant, version. Written as 2026-09-06-oak-chair-front-white-v3.jpg. Lowercase, hyphens, no spaces, 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 a file name?
| 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 behaviour 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 one 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 and are read as word separators by search engines, while underscores are not. Since product images often become URLs, hyphens are the safer default. 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 judgement. 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 most teams 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” in wherever you track assets.
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, colourway. 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 catalogue, 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, colour profile and file format do not belong in the name when the extension and the file’s own metadata already carry them.
How do you apply this to files you already have?
Do not rename the back catalogue. 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, write it into the workflow that produces the files, then run the same workflow on the rest of the catalogue so the five hundredth file is named the way the first one was. DesignerBox keeps every generation in one searchable library, so a set stays findable even where the filename is not doing the work, and 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 are read as word separators in URLs, while underscores are not. Product images frequently become URLs. The important part is choosing one and applying it everywhere.
Why should file names avoid spaces?
Spaces become %20 in URLs, break unquoted arguments on the command line, and split filenames in scripts. Any image that ends up on a website inherits its filename into the URL, so a space creates a URL that is harder to read and easier to break. Hyphens do the same job with none of the problems.
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 (support.google.com, accessed September 2026)
Naming conventions drawn from standard digital asset and records management practice. Platform requirements verified from primary sources as of September 2026. Individual results vary.
