Naming Conventions for a Product Image Library

What a file name should encode (and what it should not)

The mistake most teams make is trying to put everything in the name. A name that reads summer-2026-red-leather-crossbody-bag-womens-accessories-front-white-background-retouched-final.jpg is accurate and useless. It is too long to scan, too fragile to sort, and it will be wrong the moment the product moves to the autumn collection.

The test for each token is simple: does this need to be known when the file is separated from every other system? If a marketplace uploader, a freelancer or a wholesale buyer receives this file alone, what do they need to identify it? That is what goes in the name. Everything else belongs in metadata, where it can be edited without renaming.

The key insight is that a name is an identifier, not a description. Descriptions are what alt text is for, and there is a separate case for keyword-rich file names on the storefront, covered in Product Image SEO: Alt Text, File Names & Schema. The two are not in conflict: your library uses the identifier convention, and your storefront export layer can generate descriptive public file names from the PIM at push time.

A convention that works: token order and grammar

Here is the pattern. It is deliberately boring, and it has survived in some form at most retailers with a serious image library.

{sku}_{variant}_{shot}{seq}_{state}.{ext}

Worked examples for a leather wallet with SKU WL-0417:

The grammar rules that make this work:

• Underscores separate tokens; hyphens live inside tokens. WL-0417 is one token because the hyphen is part of the SKU. This lets any script split on _ and get exactly four or five fields, every time. Pick one separator convention and never mix them.
• Lowercase everything except the SKU. SKUs are often case-sensitive in the PIM, and most filesystems are not. Keep the SKU exactly as the PIM has it and lowercase the rest.
• Zero-pad sequence numbers to two digits. detail02 sorts after detail01 and before detail10. detail2 does not. If you ever expect more than 99 shots of one variant, pad to three, but you almost certainly will not.
• Use a closed vocabulary for shot types. Eight to twelve codes cover most catalogs: front, back, side, top, detail, flat, model, ghost, scale, pack, life. Publish the list. A shot type that is not on the list is not a valid file name.
• Variant codes come from the PIM, not from the photographer. If the PIM says the colour is cognac, the file says cognac, not tan, brown or light-brown. A mismatch here is the single most common reason images fail to auto-attach to variants during a bulk import.
• No spaces, no accents, no punctuation beyond - and _. Spaces get URL-encoded to %20, accents get mangled by at least one system in every pipeline, and a full stop in the middle of a name confuses extension detection.

Versioning without version numbers

Version numbers in file names are where conventions go to die. v2 tells you nothing about what changed, and the moment someone makes a v3 from v1 instead of v2 the sequence is meaningless. Yet the underlying need is real: a retouched image gets re-done, a background gets swapped, a colour gets corrected, and you need to know which is current.

Two approaches handle this cleanly.

The second pattern is worth adopting even if you do not use AI tools yet, because it maps directly onto how batch processing works. When a tool such as Retouchable processes a source image, the useful output name is the source name plus a short suffix describing the operation, so WL-0417_tan_front01.jpg becomes WL-0417_tan_front01_nobg.png and the lineage is obvious without opening a single file. That lineage is precisely what gets lost when outputs are named download (3).png.

Whichever approach you pick, the rule is the same: the name identifies the asset; the storage layer tracks history. Do not try to make the file name do both.

Matching the convention to marketplaces and platforms

A well-designed library convention should let you generate any channel's required file name from the tokens, rather than hand-renaming for each upload. This is where the SKU-first ordering pays off, because most marketplaces key images on a product identifier.

Notice that Shopify barely cares what the file is called. It cares about position, because position 1 is the featured image that drives collection grids and in-store search, and it cares about alt text. The convention's job there is to make position and alt text derivable without a human deciding them per image. If you run a Shopify store, Shopify Image Metadata: Alt Text, Filenames, Order goes through exactly what each field does once the file lands.

Enforcing it: validation at the door, not audits later

A convention that lives in a Notion page is a suggestion. A convention that rejects bad file names at upload is a system. The difference in outcomes is total: teams with upload-time validation stay clean for years; teams that rely on quarterly clean-ups are permanently at 60 to 70 per cent compliance, which for search purposes is the same as zero, because nobody trusts the results.

Validation does not need to be sophisticated. A single regular expression covers the whole convention:

^[A-Z]{2}-\d{4}_[a-z0-9-]+_(front|back|side|top|detail|flat|model|ghost|scale|pack|life)\d{2}(_(raw|master|wip|nobg|grey|white))?\.(jpg|png|tif|cr3)$

Adjust the SKU pattern to match yours, and put the check wherever files enter the system:

• DAM upload hooks. Most DAM platforms support an upload rule or a webhook. Reject on mismatch, with the error message showing the expected pattern and one valid example.
• A watched folder for the photographer. A small script that moves valid files into /inbox/ok and invalid ones into /inbox/fix, with a log. This catches problems while the shoot is still fresh and the photographer can re-export in seconds.
• Pre-commit for anything in Git. If marketing assets live in a repo, the same regex runs as a pre-commit check.
• The PIM as the source of vocabulary. Variant codes and SKUs should be looked up, not just pattern-matched. A file named WL-0417_tann_front01.jpg passes the regex and fails the lookup, which is the failure you actually care about.

Then measure it. Compliance is a number you can put on a dashboard, and it is one of the few asset-management metrics that directly predicts how long the next catalog refresh will take.

The first two bars are the ones to attack. A PIM lookup fixes the first. For the second, the fix is upstream: any tool that generates images should name its outputs from the input name plus an operation suffix, so nothing ever needs a manual rename after processing.

Migrating a library that is already a mess

Most teams reading this do not have an empty library. They have 20,000 files across Dropbox, a photographer's hard drive, three Shopify exports and a folder called NEW NEW. The tempting plan is a big-bang rename. The plan that works is smaller.

1. Freeze the front door first. Turn on validation for new uploads before you touch a single old file. Otherwise the mess grows while you clean it.
2. Rename only live products. Pull the list of active SKUs from the PIM or Shopify. Images for discontinued products go into an /archive folder untouched. In most catalogs this cuts the job by half or more.
3. Match by what you can trust. Perceptual hashing or a plain comparison against the images currently attached to each product in Shopify gives you a SKU for every live image, even the ones called IMG_4471.jpg. Once the SKU is known, the variant usually follows from which variant the image is attached to.
4. Infer the shot type, then check it. Gallery position is a reasonable proxy: position 1 is almost always front, and images with a person in them are model. Run the inference, then have someone eyeball a contact sheet per SKU rather than per image. A contact sheet of 40 SKUs takes ten minutes to check; 240 individual images take an afternoon.
5. Rename with a mapping file, not in place. Generate a CSV of old_path,new_path, review it, then apply it. The CSV is also your rollback and your audit trail.
6. Re-link, do not re-upload. If the DAM or storage layer supports renaming without changing the underlying object, use that. Re-uploading breaks every existing URL and can, in the worst case, reset the storefront's image cache.

A migration done this way is a week of part-time work for a catalog of a few thousand SKUs, most of it review rather than typing. The folder structure and tagging layers that sit on top of the naming convention are covered in How to Organize a Large Product Image Library; the naming convention is the foundation those layers depend on, which is why it is worth getting right first.

The one-page convention to hand to your team

Write it down in under a page, pin it where files get uploaded, and include one valid example per shot type. A convention nobody can remember is one nobody follows. Here is a template you can adapt:

The convention in this guide is not the only valid one. Some catalogs put the shot type before the variant because they shoot one angle across every colourway in a row; some use numeric shot codes for compactness. What matters is not which order you choose but that the order is fixed, the vocabulary is closed, the SKU comes first, and a machine enforces it at the point of entry. Get those four things right and every other part of managing product imagery, from bulk marketplace uploads to AI batch processing to the next catalog refresh, gets measurably easier.