How I set up QR code labels for assets, shelves, and packaging

QR code labels are where small mistakes multiply. One bad spreadsheet column can put the wrong destination on every shelf, box, folder, or asset tag.

I start with the label inventory, not the QR design. One row should describe one label: what it is, where it goes, what URL it opens, and what file name should be exported.

Make the sheet explicit

One row, one label, one destination

For a batch of QR code labels, I want a plain CSV with stable columns. Usually that means label text, destination URL, file name, location, and a note for the proof sheet.

Before I generate codes, I check for blank URLs, duplicate file names, old test rows, and destinations that point to staging or a draft page. This is easier in the CSV than after 200 PNG files exist.

If the labels are for physical assets, I keep the asset ID in the label text and the file name. A QR thumbnail is not enough when someone needs to match the right code to the right shelf or machine.

Choose static or dynamic labels

The replacement cost decides it

Static QR labels are fine for destinations that will not change: permanent documentation, public PDFs, archive folders, or internal pages that have stable URLs.

Dynamic labels are safer when the label is hard to replace or the destination may change. Equipment support pages, product packaging, long-lived storage labels, and customer-facing shelf tags usually deserve that repair path.

I avoid mixing static and dynamic codes in the same printed batch unless the label sheet says which is which. Otherwise future support becomes guesswork.

Handle duplicates before export

Duplicate labels are sometimes valid

Not every duplicate is a mistake. A storage room might need the same reorder link on three shelves. A product batch might use one support URL across several boxes. I still mark those duplicates intentionally in the sheet before export.

The dangerous duplicates are accidental file names and copied destinations. If two rows export to shelf-a.png, one QR image can overwrite the other. If a copied URL stays on the wrong row, the printed label looks correct until someone scans it.

I add a quick duplicate check before generation. Duplicate destinations get a human-readable reason. Duplicate file names get fixed. Blank labels and blank URLs do not go to the generator.

For recurring batches, I keep a clean template CSV with example rows removed. The next batch should start from the column structure, not from last month's live data. That prevents old shelf names, retired products, and temporary test URLs from sneaking into a new label run. I also keep the export date in the file name so old batches are easy to spot during later reprints and quick audits.

Keep the QR code readable

Labels are often smaller than the design preview

DENSO WAVE documents QR Code capacity and error correction, but the label still has to survive the real print conditions. Small labels, thermal printers, matte stock, glossy stock, and textured packaging all change how clean the modules look.

I keep the encoded URL short and leave quiet space around the code. The label border, cut line, hole punch, folder edge, or shelf lip should not crowd the QR modules.

If the label printer is low resolution, I make the QR code larger before I change anything else. A code that looks neat in the browser can turn soft on a small thermal or office label printer.

For labels that people scan quickly, I use one clear text line. A manual label says Scan for manual. An inventory label says Scan for inventory record. A reorder label says Scan for reorder form.

Proof the batch

Scan against the manifest

For batch labels, I print a proof sheet with the visible label text next to each QR code. Then I scan a sample and compare the opened page with the row in the manifest.

I keep the proof order the same as the CSV order. If the file export sorts by name but the sheet sorts by shelf, I fix the source before printing. A batch should be easy to audit from left to right.

I sample the first label, last label, a few middle labels, and any row with a long URL or unusual characters. If the batch is for multiple locations, I scan at least one label per location.

The most common problem is not the QR generator. It is the source sheet. A copied URL points to the wrong product, a duplicate file name overwrites another code, or a label gets sorted without its destination column.

Apply labels in a controlled order

Installation is part of the data workflow

For shelves, bins, and equipment, I apply labels in the same order as the manifest. If someone peels labels randomly from the sheet, the batch can be correct on paper and wrong in the room.

After installation, I scan a few labels in place. Lighting, shelf angle, plastic covers, and curved surfaces can change the scan more than the proof sheet did.

For customer-facing labels, I also check the page on mobile data, not only office Wi-Fi. A label on packaging or a shelf tag has to work for the customer standing there, not just for the person who printed it.

If the labels are going to another team for installation, I send the manifest with the printed sheets. The instruction is simple: place the label, scan it, and compare the opened page with the row. That catches swapped labels before the room is finished.

Keep the source files

Labels get reordered and relabeled

I keep the CSV, generated images, manifest, print size, proof notes, and approval date together. If the labels are dynamic, I also save the campaign IDs and current destinations.

That record matters when a shelf moves, a product changes, or a location needs a partial reprint. I can regenerate the affected labels instead of rebuilding the whole batch from memory.

A QR code label should make lookup faster. If the label is hard to scan, points to the wrong record, or cannot be traced back to the source row, I fix the batch before it reaches the printer.