How to Design a SKU Scheme That Stays Readable, Unique, and Scannable
Design a SKU scheme that encodes category, color, and size into a fixed, readable code. Why sequential-only SKUs fail, and how to keep them unique and scannable.
How to Design a SKU Scheme That Stays Readable, Unique, and Scannable
A SKU (stock-keeping unit) is the internal code you stamp on every sellable variant so your warehouse, your spreadsheet, and your storefront all point at the same shelf. Get the scheme right and a picker reads the code off a label and knows exactly what to grab. Get it wrong and you spend the next two years untangling near-duplicate codes that should have been one.
The mistake almost everyone makes at the start is treating a SKU as a counter. You add product number 1, then 2, then 3, and the SKU is just that number with a prefix. It feels tidy for a week. Then a customer asks why their order shipped in the wrong size, and you realize SKU PROD-0427 tells nobody on your team anything at all.
Why Sequential-Only SKUs Fail
A pure running number carries zero meaning. 00001, 00002, 00003 are unique, sure, but they force a lookup for every single decision. The picker can't tell a small black t-shirt from an extra-large white one without scanning into a system or pulling up a screen. That lookup is the cost, paid hundreds of times a day.
Sequential codes also fail the moment two people touch the catalog. Person A enters a new variant and grabs the next number. Person B, working offline that morning, grabs the same number. Now you have two products fighting over one code, and your stock count quietly splits in half. A scheme that derives the code from the product's own attributes sidesteps this: the same blue medium t-shirt always resolves to the same code, no matter who types it.
And a bare number sorts badly. Without padding, a plain text sort orders your list 1, 10, 11, 2, 3 because it compares character by character, not by value. Your inventory report becomes unreadable exactly when you need it most.
Encode Attributes Into Fixed Segments
A good SKU encodes the variant's intrinsic attributes into fixed segments, broad to specific, so the code reads like a sentence and sorts like a database key. The pattern I reach for is:
CAT-COLOR-SIZE-001
Each segment is a short, fixed-length token. Category first, then color, then size, then a zero-padded sequence to guarantee uniqueness. TS-BLK-M-001 decodes at a glance as t-shirt, black, medium, unit 001. No lookup, no screen, no spelling it out over the phone.
The key constraints that make this work:
- Fixed width per segment. Two or three characters per attribute keeps columns aligned in a spreadsheet, so codes line up and sort cleanly.
- Broad to specific ordering. Category before color before size means a sort naturally groups all your t-shirts, then all the black ones, then by size.
- Zero-padded sequence.
001not1, so codes stay equal width and sort in true numeric order through 999. Use four digits if a family will exceed a thousand variants. - Letters, digits, one separator. A single dash, or no separator at all. Nothing else.
One rule matters more than the rest: a SKU encodes attributes, never price. Price changes. Suppliers change. The moment you bake $19 or a vendor code into the SKU, you are one repricing away from a code that lies, and your only options are to keep the wrong code or reprint every label. Encode only what is intrinsic and stable over the variant's life — color, size, model. That is the whole discipline.
A Worked Example: One T-Shirt, Two Colors, Three Sizes
Say you are launching a single t-shirt in black and white, in small, medium, and large. That is two colors times three sizes, six variants. Typing six SKUs by hand is survivable; typing forty-eight (eight colors, six sizes) is where the typos start. Either way, the scheme is identical.
Fix the prefix to TS. List the colors as Black, White and the sizes as S, M, L. Walk every color-by-size combination, append a zero-padded counter, and you get the full grid:
TS-BLK-S-001
TS-BLK-M-002
TS-BLK-L-003
TS-WHT-S-004
TS-WHT-M-005
TS-WHT-L-006
Six codes, each unique, each readable, each sortable. Drop the black variants together at the top, then the white ones, sizes ascending within each. The sequence at the end is the safety net: even if two variants somehow shared every other segment, the counter keeps them distinct.
When the line grows to eight colors and six sizes, the exact same setup emits all forty-eight, TS-BLK-XS-001 through TS-WHT-XXL-048, with the sequence already padded. Paste that as CSV straight into a product import and every variant ships with a clean code from day one. The SKU code generator builds this grid for you: define the segments once, list the values, and it produces the cartesian product with auto-numbering, ready to copy as a newline list or CSV.
Keeping Them Unique and Scannable
Two failure modes break a SKU once it leaves your spreadsheet: collisions and bad characters.
Collisions are handled by the sequence. As long as the trailing counter is part of the scheme, two variants can never produce the same code, even if you accidentally duplicate a color name. The auto-increment is doing quiet, important work.
Bad characters are subtler. A space splits a code into two columns on CSV import. A slash corrupts a file path or URL. A # truncates a link. So restrict every SKU to A-Z, 0-9, and a single dash. If you find yourself wanting a slash to mean "or," resist — Size/XL should become the token SIZEXL, never a code your point-of-sale silently mangles.
The SKU is your human-readable handle, but it is not the thing a scanner reads at the till. That job belongs to a barcode (UPC or EAN), a globally registered number meant for machines. You usually want both: the SKU to organize and read aloud, the barcode to scan. Once your variant codes are settled, feed them into a barcode generator so each printed label carries the readable SKU above the scannable barcode, and the two stay in lockstep because they came from the same list. If you ever need a guaranteed-collision-free internal identifier for a database join rather than a shelf label, a UUID generator covers that separate need — but a UUID is unreadable on a pick list, which is exactly why you still want a structured SKU on top.
The Short Version
A SKU should be short enough to fit on a label, unique enough that two variants never collide, and readable enough that a person decodes it without a lookup. Encode stable attributes in fixed segments, order them broad to specific, pad the sequence with zeros, and ban every character except letters, digits, and one dash. Do that once, at the start, and you never spend a weekend reconciling near-duplicate codes again.
The structure is the whole point. A counter gives you uniqueness and nothing else. A scheme like CAT-COLOR-SIZE-001 gives you uniqueness, sortability, and a code a human can actually read — which is the only kind worth printing.
Made by Toolora · Updated 2026-06-13