Product Image File Naming: A Convention That Scales

Somebody asks for the back view of TS-4410 on a white background. You open the shared drive and find IMG_4471 copy 2 final.png, IMG_4471 copy 2 final (1).png, and a folder called NEW EDITS USE THESE. Ten minutes later you are still opening thumbnails.

A naming convention is the cheapest fix in catalogue operations: an afternoon of agreement, no new software, and it outlasts whoever shot the photos. Here is a scheme that holds up across a few thousand files.

Put the SKU first, every time

Filenames sort alphabetically, so the first field is the axis your folder is organised by. Make it the identifier that never changes: the SKU exactly as it appears in your product feed. Every image of a product then sits together, whoever saved it.

Dates first (2026-07-14_shoot_final) group by shoot day, the one axis nobody searches on.

Three fields is enough:

• TS-4410 — the SKU, verbatim from the feed
• MAIN — what the camera is looking at
• white — what is behind the subject

Joined up: TS-4410_MAIN_white.png. Anyone reading that list knows what it is without opening it, and a script splits it on the underscore.

Agree the view codes before anyone shoots

The second field only works with a fixed, written vocabulary. Invent codes once and never improvise: MAIN for the hero shot, PT01 through PT08 for additional views in a set order, ALT-back, DETAIL-clasp, SCALE.

Zero-pad the numbers — PT01, not PT1. Windows Explorer and Finder sort numbers naturally, but shell listings, scripts and object-storage keys sort as plain text, so PT11 lands between PT1 and PT2 instead of after them.

Amazon's own image file-name rule lives in the Seller Central help pages, behind the seller login, and may not use the same separators as here. Check the current syntax in your account before renaming thousands of files, and keep the underlying idea — identifier first, view code second — on every channel (Amazon product image rules).

Name the background, not just the product

One photo becomes several deliverables: plain white for a marketplace, brand colour for a banner, transparent for a deck, a drop shadow for the category grid. If the name does not say which is which, you ship the wrong one.

Use a short, closed list for the third field: raw for the untouched camera file, white, brand, cut for transparent, shadow, and life for a lifestyle backdrop. When you replace a background in remover.bg — solid colour, custom colour, or your own photo — know which suffix that output is going to get before you start, and rename the download straight away.

The extension carries information too. Transparent output has to be PNG or WebP; a _cut file saved as JPEG is a bug, not a variant (transparent PNGs explained). Marketplace white files are usually JPEG, site images increasingly WebP.

Characters that quietly break things

• No spaces. They become %20 in URLs, break unquoted shell scripts, and get silently rewritten by upload forms.
• ASCII only. # and ? end the path portion of a URL and & separates query parameters, so any of them in a filename can truncate or split a link. Accented and other non-ASCII characters fall outside the permitted URI character set and get percent-encoded into unreadable strings. Parentheses are legal in a path but still break markdown links and unquoted shell commands.
• One fixed case. Windows and macOS are case-insensitive by default, so TS-4410 and ts-4410 collide; Linux servers and object storage keep two files. Enforce one case.
• One separator per level. Underscore between fields, hyphen inside a field.
• No status words. final, FINAL2, new, use-this are lies within a week. Version by replacing the file, not renaming it.

Keep the camera original and the cutout apart

Never overwrite the source. TS-4410_MAIN_raw.jpg and TS-4410_MAIN_white.jpg live side by side, so when the brand colour changes you re-cut from the original instead of rescuing a flattened export.

Uploads are capped at 25 MB, which a large camera file can exceed. Shrink it in your own photo editor first — that reduced copy is a third artefact, so give it a name (TS-4410_MAIN_upload.jpg).

Naming is what makes bulk runs possible

Batch processing runs through the HTTP API, so every file is addressed by name. Deterministic names give a deterministic job: the script reads TS-4410_MAIN_raw.jpg, writes TS-4410_MAIN_cut.png, and re-runs safely: the output path is a pure function of the input.

Diff expected output names against what landed, and the gap names the SKU that failed. The background removal API guide covers the request side.

The rule card

Pin this to the shared drive:

1. SKU_VIEW_BACKGROUND.ext, in that order.
2. SKU copied from the feed, character for character.
3. View from the agreed list. Numbers zero-padded.
4. Background from the agreed list. Extension matches it.
5. One fixed case, ASCII only, no spaces, no dates, no status words.
6. Originals kept as _raw and never overwritten.

Rename the last hundred files by hand this week. Everything after that is free.