Artwork File Naming Convention for Packaging and Print Workflows

Why file naming breaks down in packaging and print workflows

Packaging teams usually do not lose control of artwork because they lack folders. They lose control because filenames do not clearly show what a file is, whether it is current, or whether it is safe to print.

That gets expensive quickly.

In real supplier workflows, poor file naming leads to problems like:

• a factory printing an outdated carton because the PDF looked newer than the AI file
• a sourcing manager sending a proof marked final that was never actually approved
• a supplier using the correct SKU but the wrong size variant
• a warehouse team receiving stock with old barcodes or obsolete shipping marks
• a designer overwriting the approved file instead of creating a new revision
• ops teams wasting hours checking inboxes, chat threads, and shared drives to figure out what changed

That is why a file naming system for artwork matters. Before anyone opens a file, the filename should answer:

• Which product is this for?
• Which component is it?
• What stage is it at?
• Which version is it?
• When was it created or released?
• Is it safe to send to a supplier or printer?

If the answer is not obvious from the filename, the file is risky.

This matters even more when one product has multiple packaging components:

• primary label
• carton artwork
• insert or leaflet
• inner carton label
• master carton label
• dieline
• print-ready export
• press proof

Once you add multiple SKUs, sizes, pack counts, languages, and suppliers, weak naming turns into version chaos. If you want to reduce reprints, start by making filenames readable, consistent, and operationally useful.

For related handoff issues, see How to Hand Off Packaging Files to Suppliers Without Version Chaos and How to Avoid Sending the Wrong Artwork Version to a Supplier.

The simple file naming formula

A practical artwork file naming convention should be simple enough that design, ops, suppliers, and QA all use it the same way.

A good default format is:

Brand_ProductOrSKU_Component_Status_Version_Date.Extension

In many teams, this becomes:

BrandName_SKU123_BoxArtwork_DRAFT_v01_2026-03-30.ai

This works because each field serves a clear purpose:

1. Brand: helpful when files move outside your system
2. Product or SKU: the core identifier that ties the file to the right item
3. Component: what the file actually is
4. Status: whether it is draft, under review, approved, or safe for supplier use
5. Version: the revision sequence
6. Date: when that version was created, approved, or exported
7. Extension: file type, which often indicates purpose

Recommended field order

Put the most important identifiers first.

A strong sequence is:

Brand_ProductLine_SKU_SizeOrVariant_Component_Status_Version_Date.Extension

Not every file needs every field. The point is consistency, not maximum length.

Core fields to include in every filename

At minimum, every file should include:

• product identifier: SKU, item code, or tightly controlled short item name
• component: Label, CartonArtwork, Insert, Dieline, Proof, PrintReady
• status: DRAFT, REVIEW, APPROVED, SUPPLIER_READY, RELEASED, OBSOLETE
• version: v01, v02, v03
• date: YYYY-MM-DD

If your SKU structure is weak, fix that first. File naming is much easier when products and variants are clearly defined. See How to Structure SKUs Properly (Before You Print Anything).

Recommended naming rules before you start

A file naming system fails when every team member improvises. Set the rules once and keep them tight.

1. Use one separator

Use underscores consistently:

BrandName_SKU123_Label_APPROVED_v02_2026-04-01.pdf

Do not mix underscores, hyphens, spaces, and brackets in the same system.

2. Use sortable dates

Always use:

YYYY-MM-DD

For example:

2026-04-08

This sorts properly in folders and avoids country-format confusion.

3. Use fixed version formatting

Use leading zeros:

• v01
• v02
• v03
• v10

Do not switch between v2, ver2, rev02, and final2.

4. Standardise status labels

Choose a small set and train everyone to use only those.

Recommended statuses:

• DRAFT
• REVIEW
• APPROVED
• SUPPLIER_READY
• RELEASED
• OBSOLETE
• ARCHIVE

If supplier markup or technical correction needs a visible intermediate step, use:

• REV-Supplier

5. Avoid vague words

Do not use:

• final
• final_final
• final-v2
• latest
• new
• updated
• use-this-one

Those names create false certainty and make audit trails useless.

6. Keep component names controlled

Use the same term every time. For example, pick one of these and stick to it:

• BoxArtwork
• CartonArtwork
• Label
• Insert
• Dieline
• Proof
• PrintReady

Do not alternate between OuterBox, RetailCarton, PackArt, and Carton unless they truly mean different things.

Naming drafts, review files, and supplier-ready files

The biggest source of confusion is usually not version numbering. It is stage control.

A useful artwork naming convention should separate files by lifecycle stage.

Draft files

Drafts are working files still being edited.

Use these for:

• design development
• copy changes
• barcode placement checks
• regulatory updates
• pre-approval revisions

Example:

BrandName_SKU123_BoxArtwork_DRAFT_v01_2026-03-30.ai

Rules:

• keep native working format where relevant, such as .ai or .indd
• only increment the version when a meaningful change is made
• do not send drafts as production files

Review files

Review files are for internal or cross-functional signoff.

Use these when:

• marketing is checking claims
• regulatory is checking required text
• ops is checking barcode, pack quantity, and country marks
• sourcing is checking supplier constraints

Example:

BrandName_SKU123_Label_REVIEW_v03_2026-04-02.pdf

Rules:

• review files should usually be PDF exports, not editable native files
• comments and approvals should happen against the specific version named in the file
• if edits are requested, create a new version rather than replacing the reviewed file

Approved files

Approved means the content is signed off internally, but not necessarily packaged for supplier handoff.

Example:

BrandName_SKU123_Dieline_APPROVED_v05_2026-04-05.pdf

Rules:

• use only after formal signoff
• do not edit the approved file directly
• if changes are needed, create a new DRAFT or REVIEW version from the working source

Supplier-ready files

Supplier-ready means safe to send for production use, subject to PO and print method requirements.

Example:

BrandName_SKU123_Insert_SUPPLIER_READY_v02_2026-04-10.indd

In many cases you will send both:

• the approved print-ready PDF
• linked or native files only if the supplier specifically requires them

This stage should align with your purchase order, specs, and production approval process. See Supplier Production Approval Checklist and How to Write a Supplier-Ready Purchase Order.

Released files

Released is your controlled source of truth for active production.

Example:

BrandName_SKU123_CartonArtwork_RELEASED_v07_2026-04-08.pdf

Use RELEASED when:

• the file is approved
• it is the current production version
• it is the version ops and suppliers should use unless superseded

For most brands, RELEASED is the clearest label for live production files.

Examples for packaging, labels, dielines, and print exports

Below is a simple naming system that works across common packaging components.

Realistic multi-file set for one SKU

For one 500ml product, a clean set could look like this:

• NorthPeak_NP500-SKU123_500ml_Label_RELEASED_v04_2026-04-11.pdf
• NorthPeak_NP500-SKU123_500ml_CartonArtwork_RELEASED_v06_2026-04-11.pdf
• NorthPeak_NP500-SKU123_500ml_Dieline_APPROVED_v03_2026-04-05.pdf
• NorthPeak_NP500-SKU123_500ml_Insert_RELEASED_v02_2026-04-11.pdf
• NorthPeak_NP500-SKU123_500ml_MasterCartonLabel_RELEASED_v01_2026-04-11.pdf

Without opening any file, a supplier can tell what belongs to the SKU and what stage it is at.

How to handle revisions without creating confusion

Packaging file version control breaks when teams overwrite files or bump versions for no reason.

When to increment the version

Create a new version when any of these change:

• artwork content
• claims or legal text
• barcode or GTIN
• color callout
• dieline dimensions
• printer marks
• language panel
• pack quantity or unit declaration
• supplier-required technical adjustment that could affect output

Do not create a new version just because the file moved folders.

When to change status instead of version

Sometimes the file content is unchanged, but the stage changes.

Example:

• BrandName_SKU123_Label_REVIEW_v03_2026-04-02.pdf
• BrandName_SKU123_Label_APPROVED_v03_2026-04-03.pdf

This can work if the approved file is simply the same artwork exported after approval. But many teams prefer to re-export the approved file with a new date for audit clarity.

How to handle supplier edits

If a supplier adjusts the file for print setup, do not silently replace the approved original.

Use a distinct status such as:

BrandName_SKU123_BoxArtwork_REV-Supplier_v06_2026-04-12.pdf

Then either:

1. approve that supplier revision and release it as the next production version, or
2. reject it and return to the previously approved file

The key rule: never let supplier-modified files blend into your controlled originals without clear naming.

Do not overwrite approved or released files

If a released file needs changing, create a new version.

Bad practice:

• opening RELEASED_v07 and saving over it

Good practice:

• keep RELEASED_v07 unchanged
• create DRAFT_v08
• move through review and approval
• release v08 only when signed off

That audit trail is what prevents reprints and disputes later.

How to label final, approved, and archived files

The word final causes more confusion than it solves. Final to design is not always final for QA, sourcing, or supplier production.

Use a simple lifecycle instead.

Recommended lifecycle

• DRAFT — being edited
• REVIEW — under internal review
• APPROVED — signed off internally
• SUPPLIER_READY — prepared for external handoff
• RELEASED — current live production version
• OBSOLETE — no longer valid for use
• ARCHIVE — retained for history only

What each status means operationally

If you need one source of truth, make your RELEASED folder the only place suppliers and internal ops teams are told to pull current print-ready files from.

A basic folder structure that supports the naming system

Folders should support the naming system, not compensate for weak filenames.

A lightweight structure might look like this:

• Artwork/
  • SKU123/
    • 01_Working/
    • 02_Review/
    • 03_Approved/
    • 04_Released/
    • 99_Archive/

Within each SKU folder, use the same naming rules for every file.

Why SKU-level folders work well

They help teams group files around the actual product being ordered, packed, and shipped.

That matters when the same product also has:

• BOM references
• barcode records
• supplier specs
• master data sheets
• carton dimensions
• 3PL onboarding data

Artwork should not live in isolation from product data. See Product Master Data Sheet: Fields Every Brand Should Include and How to Prepare Product Data for 3PL Onboarding.

Common mistakes that cause supplier errors

These are the failure points that show up most often in real artwork handoffs.

Using the same filename for different files

If SKU123_Label_Final.pdf exists in three folders, someone will send the wrong one.

Leaving out the SKU or variant

A label for 250ml and 500ml should never have near-identical names without a size field.

Treating native files as released production files

Your .ai or .indd file is not always the right source for print. In many cases, the released production reference should be a controlled print-ready PDF.

Mixing status terms

If one team uses FINAL, another uses APPROVED, and a supplier uses LATEST, your file naming system is already broken.

Archiving informally

Moving old files into a random old folder is not enough. Mark them OBSOLETE or place them in a controlled archive location.

Sending files outside a controlled package

Even the best label file naming convention can fail if the supplier gets files through scattered email threads. Tie the artwork handoff to:

• the PO
• the SKU
• pack details
• quantity
• print specs
• approval status

If barcodes are involved, make sure the filename and the product record point to the same GTIN. See How to Get a GS1 Barcode (Step-by-Step Guide for Brands & Founders).

Template: copy this naming system for your brand

Use this as a starting point.

Standard filename template

Brand_ProductLine_SKU_SizeOrVariant_Component_Status_v##_YYYY-MM-DD.Extension

Remove any field you truly do not need, but keep the order consistent.

Controlled component list

Use a fixed list such as:

• Label
• CartonArtwork
• BoxArtwork
• Insert
• Leaflet
• Dieline
• Proof
• PrintReady
• MasterCartonLabel
• InnerCartonLabel

Controlled status list

Use only:

• DRAFT
• REVIEW
• APPROVED
• SUPPLIER_READY
• RELEASED
• REV-Supplier
• OBSOLETE
• ARCHIVE

Quick-start checklist

• Define one product identifier format for every item
• Decide your standard component names
• Decide your approved status labels
• Use v01, v02, v03 version formatting
• Use YYYY-MM-DD date formatting
• Stop using final, latest, and new
• Separate working, approved, released, and archived files
• Do not overwrite approved or released versions
• Make one folder the source of truth for released files
• Train design, ops, sourcing, and suppliers on the same rules
• Include the exact released filename in supplier approvals and production records

FAQ

What is the best file naming system for artwork files?

The best system is one that shows product identifier, component, status, version, and date in a consistent order. For most brands, a structure like Brand_SKU_Component_Status_v##_YYYY-MM-DD.ext works well.

Should I use dates or version numbers in packaging file names?

Use both. Version numbers show sequence. Dates show timing. Together they make packaging file version control much clearer.

How do I name supplier-ready artwork files?

Use a clear status such as SUPPLIER_READY or RELEASED, and include the SKU, component, version, and date. Example: BrandName_SKU123_CartonArtwork_RELEASED_v07_2026-04-08.pdf.

What should go in a print file name for packaging?

At minimum include:

• SKU or product code
• component type
• status
• version number
• date
• file extension

If variants matter, add size, colorway, language, or pack count.

How do I stop people from using the wrong artwork version?

Use one released-files location, clear statuses, fixed version numbering, and explicit obsolete marking. Also stop sending files through loose email chains. A controlled handoff process matters as much as the filename.

Should final files be called final or approved?

Use APPROVED or RELEASED, not final. Final is too vague and often gets reused across multiple rounds.

How do I name dieline files correctly?

Use the same structure as artwork files, but make the component explicit. Example: BrandName_SKU123_Dieline_APPROVED_v05_2026-04-05.pdf.

What is the best way to archive old artwork versions?

Do not just move them into an old folder. Mark them OBSOLETE or move them into a controlled archive folder while preserving the version and date in the filename.

Final note

A good artwork file naming system will not solve every packaging workflow issue on its own. But it removes one of the most common causes of supplier confusion: nobody knows which file is safe to use.

If your brand manages multiple SKUs, suppliers, packaging components, and print cycles, standardising filenames is a low-cost fix with immediate operational impact.

If you want to go further, SKUWorks can help keep artwork, product data, supplier files, and release status tied to the right SKU so teams are not chasing approvals across folders and inboxes.