Product Image Naming Convention: Stop Sending the Old Photo

The quote you sent last week was built on a photo from 2024. The buyer priced the old base plate, you shipped the new one, and the argument that followed was not about engineering or price — it was about which file was the truth. Nothing in the name of that photo told either of you the answer.

A product image naming convention is a fixed, machine-sortable pattern applied to every photo of every SKU, so that a file can be identified — product, view, version, date — without opening it, and so that two people in two countries can tell which one is current. It is not tidiness. It is the only cheap evidence you have that the photo you approved is the photo that went out.

Here is the pattern, the tokens that carry real information, the three places a name breaks, and the order to rename an existing library without breaking live listings.

What a product image naming convention has to do

A file name has three jobs, and most suppliers design for the first only.

The third job costs money. A supplier who cannot point to the approved file has no defence when a buyer says "this is not the finish we agreed" — even when the finish is right. In a folder where the newest file is the one named "(1)", nobody can reconstruct what was sent in March.

The five tokens, in this order

Order matters more than vocabulary: a fixed sequence makes an alphabetical sort produce a usable list — one SKU together, views in fixed order, newest last.

The full name reads SM-CB-1200_front_v03_2026-10-29.jpg — 38 characters, no spaces, nothing that needs escaping, and it sorts correctly in Finder, Explorer and Google Drive.

The SKU comes first because the buyer's filing system is keyed to it: that is the number on the PO. A name starting with the product name — walnut-cabinet-1200mm-2.jpg — scatters one SKU across the alphabet as soon as you sell it in two finishes. The date is a separate token because the version says what changed and the date says when the buyer could have seen it; when a claim arrives six months later, the date settles it.

Nail this one down: a file name is not a label, it is the only record of which photo you approved.

The view token: a closed list, not a description

Free-text view names are where conventions die. Close the list at the values you actually publish.

Nine values cover nearly every enquiry; if a tenth appears, add it in writing first — a convention that lives in one person's head is not one.

dim and scale get confused constantly. dim is the measured drawing; scale is the in-context shot. A buyer checking a doorway needs scale; a buyer filling a quote needs dim. When both live under one name, the wrong one gets forwarded.

Version and date are not the same field

The version token answers "is this the same product as before"; the date answers "when did this become the file of record". They diverge the moment a photo is re-shot without the product changing — a cleaner background, a better-lit finish — which is exactly the case that causes disputes, because the product looks slightly different and the buyer assumes the specification moved.

Three rules, written down where the team can see them:

• Version increments only when the product, the finish or the measurement changes. A lighting-only re-shoot keeps the version and takes today's date, with -res appended if you keep both: SM-CB-1200_front_v03_2026-10-29-res.jpg.
• The approved file keeps its name forever. A new file moves the old one into archive/ with its name intact — never renamed to old, never overwritten.
• Nothing is sent from archive/. If a buyer wants last season's photo, it goes out renamed with its own date so the file still identifies itself.

That last rule is what the version token is for: an overwritten file at the same name is unfalsifiable. The same discipline appears in a product spec change checklist, where the version has to travel to every document at once.

A worked example: one enquiry, three SKUs

A buyer asks for a 1,200 mm walnut cabinet, a 900 mm version, and the flat-packed carton. The reply is six files, chosen by name alone:

Two things fall out that a folder of 40 unsorted photos cannot give you. The two models were shot two weeks apart, and the dates make that visible — useful when a buyer asks whether the 900 mm cabinet got the new hinge. And every file names its own job, so the engineer, the freight forwarder and the showroom manager each take what they need without a second email.

This is the same principle behind a one-product spec sheet: one SKU, one page, one job. A product image naming convention is that principle applied to the files the page is built from, and it is what makes the furniture listing annotation case study reproducible across a catalogue instead of a one-off. It is also the precondition for reusing product images across platforms without guessing which asset belongs to which channel.

The three places a file name breaks

None of these are style opinions. Each silently splits the library in two.

1. Path length: 260 characters on Windows

Windows caps a full path at 260 characters, with 255 for a single name. A file that opens fine in a test folder becomes unopenable three folders deep in a client's download directory. Long descriptive names plus deep folders are how a good file becomes "file not found" on the buyer's machine.

Keep the whole name under 60 characters and the folder path under 150, and the problem disappears. That is the practical reason not to embed the product title: it is long, it duplicates the SKU, and it is the first thing that gets trimmed.

2. Reserved characters, spaces and case

Windows forbids < > : " / \ | ? * and reserves names such as CON, PRN, AUX, NUL. In a URL the rest gets mangled: a space becomes %20, # truncates the link at the fragment, ? turns the remainder into a query string. The file opens on your laptop and returns a 404 in a WeChat message.

Case is the quieter trap: Windows and macOS compare names case-insensitively by default, so SM-CB-1200_front.jpg and sm-cb-1200_front.jpg are one file on a Mac and two objects on a Linux server. Upload both and you cannot say which the listing shows.

Use lower-case letters, digits, hyphens and dots only. Hyphens survive every client, gateway and URL parser; underscores and spaces do not.

3. Accents and Unicode normalization

Two characters can look identical and be different bytes. "é" can be one precomposed character or e plus a combining accent; macOS compares names normalization-insensitively, Linux servers and cloud storage generally do not. Copy a folder from a Mac to a server and one accented name can become two files — or one file that overwrites the other.

If the catalogue includes accents or Chinese characters, keep the file name ASCII and put the local name in the product data, so the file works on every machine in the chain.

A fourth break is not about the name: a CDN serves a file by URL, and caches keep serving the old image after you replace it at the same path. A version token fixes this for free — a new version is a new URL, so nothing is stale, and the URL doubles as an audit trail.

Renaming the library you already have

Applying a product image naming convention to an existing library is the part everyone postpones. Do not start with the 4,000 files; start with the files that are live.

1. Export the SKU list from the quotation system, not the photo folder — the folder is missing live SKUs and full of dead ones.
2. Mark the SKUs on a listing, catalogue or quote in the last 12 months — usually 10 to 20 percent of the library.
3. Rename those, newest file first, and drop the older versions into archive/ with names unchanged.
4. Update the references the same day: a renamed file is a new URL, so anything still pointing at the old path breaks visibly instead of silently.
5. Leave the long tail until it is needed. A rule enforced on 200 live SKUs beats a perfect one applied to none.

The failure mode of a big-bang rename is well known: a folder is renamed on Friday, the listing goes blank over the weekend, and the convention is abandoned as "the thing that broke the site". Order the work by what is published and the migration costs an hour, not a week.

Pre-send checklist

• Name starts with the SKU exactly as printed on the carton and the quote
• The view value comes from the closed list, not from memory
• Version changed only because the product, finish or measurement changed
• Date is ISO 8601 and is the approval date, not the shoot date
• Hyphens only, lower case, no spaces, no accents, no # or ?
• Whole name under 60 characters, and it still opens three folders deep
• The older version sits in archive/ with its original name intact
• Every live listing, catalogue page and saved quote points at the current file
• The dim file and the scale file were not swapped

FAQ

What is a good naming convention for product images?

A good convention is SKU_view_version_date.extension, all lower case, tokens in that fixed order. It carries the four facts a colleague or buyer needs — which product, which view, which revision, approved when — and it sorts correctly in any file browser without a database.

Should the SKU or the product name come first in an image file name?

The SKU, always. It appears on the purchase order, the carton and the invoice, so it is the number the buyer's filing system is keyed to. Product names vary by market, finish and language, and a library sorted by product name splits one SKU across the alphabet as soon as a second finish exists.

What characters should I avoid in product image file names?

Avoid spaces, #, ?, %, &, <, >, :, ", /, \, |, *, and accents or non-Latin characters. Windows forbids several outright, a space becomes %20 in a URL, and # silently cuts the link short. Hyphens are the safest separator.

How do I name photos that show different views of the same product?

Give each view one fixed token from a closed list — front, main, dim, detail, scale, pack, assembled, packed, break — and never invent a new word for a one-off request. The list is what makes an alphabetical sort behave like a contact sheet: every view of one SKU lands together, always in the same order.

Where does the version number go when a product photo changes?

Immediately after the view token, before the date, and it increments only when the product, finish or measurement changes — not when the lighting improves. Re-shoots that change nothing but the exposure keep the version and take a new date. When the file itself has to change and the version cannot move, append a suffix such as -res so the two files remain distinguishable forever.

If the version jumps because a dimension changed, renaming cannot fix it: the old drawing now carries a number that no longer matches the product. That is where a workflow earns its keep — measure once, lock the value to the product's real edges on the photo, re-export at the size each channel expects, so the new version comes from the same source instead of being redrawn by eye. A generated scene can restyle a shot; only a measured value belongs on a dim file.

Sources & References

• Microsoft Learn — Naming Files, Paths, and Namespaces (reserved characters, reserved device names, 260-character path limit)
• RFC 3339 — Date and Time on the Internet: Timestamps (the YYYY-MM-DD date format derived from ISO 8601)
• GS1 — GTIN identification keys for trade items
• Unicode Standard Annex #15 — Unicode Normalization Forms (precomposed vs combining characters)
• RFC 3986 — Uniform Resource Identifier: reserved characters and percent-encoding
• AWS — Invalidating files in CloudFront (cached objects are keyed to the request path)