Short answer
A Meesho SKU ID is the product code you entered when uploading your catalogue, printed on every shipping label for that variant. Meesho does not generate it. One product often carries several SKU IDs because of relists, colour variants and price tests.
Key takeaways
- The SKU ID on a Meesho label is the identifier you typed when you uploaded the catalogue, not something Meesho generated.
- One product commonly carries three or four SKU IDs because of relists, colour variants, price tests and typos.
- The fix is a mapping: many SKU IDs on one side, one product name you actually use on the other.
- The rule that keeps it sane: a product can own many SKU IDs, but a SKU ID belongs to exactly one product.
- Do not retype your catalogue. Pull the SKU IDs out of a label PDF you already have.
Look at any Meesho shipping label and you will find a small table near the middle: SKU, Size, Qty, Color, Order No. The SKU column holds a string like 2pc_COMB0_LEGEND or 765_REDCOLOR_LIONPRINT.
That string is doing more work than most sellers realise, and understanding it is the difference between a packing table that runs itself and one that needs you standing next to it. This guide is for Meesho sellers who are tired of decoding their own SKU IDs at the shelf.
Scope: this is about reading and organising the SKU IDs you already have. It does not cover catalogue creation, pricing or how Meesho ranks listings. I build the free label tool linked at the end, which is one way to apply the mapping described here, but the naming advice stands on its own.
On this page
Where the SKU ID comes from
The SKU ID is not generated by Meesho. It is the identifier you supplied when you uploaded the catalogue. Whatever went into the SKU field of the catalogue upload sheet is what prints on every label for that variant, for as long as the catalogue is live.
That has one immediate consequence. Your SKU IDs are exactly as readable as you were careful on the night you uploaded a hundred products in a hurry. If you typed t1, t2, t3 at 11pm, your labels now say t1, t2, t3, and they will keep saying that.
Meesho's own supplier panel is where the catalogue and its SKUs are managed, so that is where you check what you actually uploaded.
Why one product ends up with several
This is the part that catches people out. A single thing you think of as one product can easily carry three or four different SKU IDs:
- Relists. You listed the product, it did not sell, you relisted it with a fresh catalogue and a new SKU. Both catalogues are still live and both still take orders.
- Colour or pack variants. The same design in black and in white can be two catalogues with two SKU roots, even though they come off the same shelf.
- Price experiments. Duplicating a catalogue to test a different price point is common, and the duplicate gets its own SKU.
- Typos and separators.
LEGEND_BLKandLEGEND-BLKare two different SKUs to a computer and one product to you.
The result is that your shelf has one box and your labels have four names for it. That mismatch is exactly why automated sorting can look wrong when it is actually correct: the software grouped by SKU, and you were thinking in products.
The fix: map SKU IDs to a name you use
The practical solution is a mapping. On one side, the product name your packing table uses. On the other, every Meesho SKU ID that means that product.
| Your product name | Meesho SKU IDs it covers |
|---|---|
| LEGEND COMBO BLACK | 2pc_COMB0_LEGEND2pc-COMBO-LEGENDLEGEND_BLK_2PC |
| LION PRINT RED | 765_REDCOLOR_LIONPRINTLION_RED_TSHIRT |
Once that mapping exists, a sorting tool can group all three SKU IDs into a single pile and print LEGEND COMBO BLACK on all of them. Your team never sees the SKU string again.
One rule keeps this sane, and it only goes one way: a product can own many SKU IDs, but a SKU ID belongs to exactly one product. If you try to put the same SKU under two products, one of them has to give it up, because otherwise the software has no way to decide which name to print. A well-built tool will enforce that for you rather than letting you create the conflict.
Do it once, from a file you already have
You do not need to retype SKU IDs out of your catalogue. The faster route is to let a tool read one of your existing label PDFs, pull out every SKU ID it finds, and hand you that list to name.
Ten minutes spent on a busy day's file usually covers ninety percent of what you ship, because a busy day's file contains your top sellers by definition. The long tail can wait.
New SKUs will appear over time, whenever you list something new. A sensible tool flags those rather than guessing: it prints the raw SKU ID on those labels and keeps them at the end of the pile so they are easy to spot and name later.
Naming SKUs better going forward
For anything you upload from here on, a small amount of discipline pays off on every future order:
- Product first, variant second.
LEGENDCOMBO-BLACK-MbeatsM-BLACK-2pc, because it sorts and scans in the order you think. - Pick one separator and stick to it. Mixing
_and-creates near-duplicates that look identical to you and different to software. - Avoid shorthand you will forget.
BLKis obvious today and a mystery in eight months. - Never reuse a retired SKU for a different product. Old returns and old labels come back and will map to the wrong thing.
- Keep it under about 20 characters. Long SKUs get truncated or wrap awkwardly in the label's table cell.
None of this is glamorous. It is also the single cheapest operational improvement available to a small seller, because it costs one evening and pays out on every order forever.
Next step
If you want the mapping set up without retyping anything, the Label Sorter collects every SKU ID from your own label PDF and lets you name them in one screen. From then on your labels print the name instead of the code. It is free and runs in your browser, so nothing is uploaded.