QR codes for inventory and product tracking

How do you use QR codes for inventory?

Put a code on each item that opens a record in your own system rather than describing the item. Keep the payload short, because payload length decides symbol size and symbol size decides whether a small label can be printed at all. Then decide, before printing, whether you need one code per product line or one per unit.

Almost every failed inventory rollout we have seen fails on one of those three decisions, and the first one is the one nobody expects.

The limit is the module, not the label

A QR code is a grid. Add characters to the payload and the grid gains rows and columns, so at a fixed label size every module gets narrower. Nothing warns you: the code renders, it looks correct on screen, it looks correct in a PDF, and it fails on paper.

Two numbers decide it. A phone camera needs roughly 0.4mm per module to read reliably in ordinary light. A 203dpi thermal label printer, which is what most warehouses run, places one dot per 0.125mm, so it cannot draw a module edge finer than that whatever the file says.

The worked example is one of ours. A GS1-128 barcode sized to a 40mm label came out at0.086mm per module, against a 0.25mm GS1 minimum and that 0.125mm printer dot. The bars could not be placed correctly even in principle. Every test passed, because they all measured modules and none measured millimetres. Our label tools now refuse those rows by name rather than printing them.

When a QR beats a barcode, and when it does not

This is a hardware question before it is a data question.

A linear barcode is right when a dedicated scanner reads a number off a shelf edge. That is the job the hardware was built for, the read is instant, and a numeric code spends less width per character than a QR spends. If your team already carries scanners, do not take them away.

A QR code is right when the scanner is a phone, when the label is square rather than long, or when scanning should open something rather than type a number into a field. It also survives damage better, because it carries error correction and a linear barcode does not.

Plenty of operations print both on one label, and that is a sensible answer rather than a hedge. If you are choosing a linear symbology, our barcode generator covers Code 128, Code 39 and GS1-128, and refuses a size that cannot be printed.

Do not encode the item in the code

The tempting design is to put the useful information into the code itself: the SKU, the description, the bin, the price. It removes a lookup, and it is wrong for a reason that only appears later.

A code that carries the data is frozen at the moment it was printed. The item moves bin, the price changes, the spec sheet is corrected, and every label in the building is now wrong. A code that carries a short link is a pointer, and a pointer can be re-aimed without touching the label. That is the same argument as dynamic versus static, and it applies with more force here, because relabelling a warehouse is worse than reprinting a poster.

It also keeps the payload short, which is what keeps the symbol small, which is what lets the label be small. The three decisions are the same decision.

One code per product, or one per unit?

Decide this first, because the two are not convertible afterwards.

One per product line is enough when the code answers "what is this": a manual, a spec sheet, a care label, a reorder page. Every unit of that product carries an identical code and that is fine.

One per unit is required the moment you need to know which unit. Serial numbers, warranty claims, returns, provenance, anything where two items of the same product must be told apart. This needs a distinct payload per label, which means generating them in bulk rather than duplicating one image. Our bulk QR tool takes a spreadsheet column and produces a sheet, and the bulk barcode generator does the same for linear symbologies.

Retrofitting per-unit codes onto a run that was labelled per-product means relabelling everything, so the cost of guessing wrong is the whole rollout.

Printing, quiet zones and damage

Three practical things, in the order they cause trouble.

The quiet zone is four modules on every side, and cropping it is the most common cause of a code that will not scan. It is part of the symbol, not a margin you can trim to fit more label.

Contrast is a print measurement, not a screen one. Scanners read with red light around 660nm, so a red code on a white label can measure fine on a monitor and be nearly invisible to the scanner. Dark on light, and keep the light side genuinely light.

Error correction buys you damage tolerance, and inventory labels get scuffed. A higher level adds modules, which makes the symbol denser at the same physical size, so it trades against the millimetre floor above. On a small label that trade is real and worth making deliberately rather than by default.