Choosing size, material, and finish
Printing bulk shelf labels starts with three choices that shape everything else: size, material, and finish. Size follows scan distance, so a code scanned at arm's length can be smaller than one scanned across a room, and labels fixed to shelf edges and read nearby needs a size tested in the real setting. Material follows the environment, including moisture, sunlight, handling, and cleaning, so short-lived indoor items can use plain paper while handled or outdoor items need laminated or synthetic stock. Finish affects glare, so a matte finish often scans more reliably than a glossy one under bright lights. Agree these three choices in writing before artwork is built, because changing material or size after layout means rebuilding the file.
Setting up the print file
Build the print file from the checked source data, not from a hand-edited copy, so the printed codes match the approved batch. Keep the quiet zone clear on all four sides of every symbol, and keep text, borders, and cut marks out of that margin. Use high-resolution exports for print, and avoid stretching or resampling the code image, because distortion blurs the module edges that scanners rely on. Place the human-readable details, such as the name and reference, where they stay visible after cutting, folding, or lamination. If the run uses sheets, check the sheet layout for alignment, margins, and cut guides before the full run, and confirm that the first and last positions on the sheet are correct, since alignment drift shows up at the edges first.
Checking the first sheets
Print a small proof run on the final stock, at the final size, and inspect it before the full run. Scan every code on the proof with two different phones, and compare each scanned destination with the source row. Look at the print itself for ink spread, faint modules, banding, or misalignment, and check that the quiet zone survived cutting and trimming. If anything fails, stop and fix the file, the settings, or the material, rather than hoping the rest of the run will improve. Once the proof passes, approve it in writing, keep a copy as the reference, and spot-check sheets during the run, especially after any paper change, ink change, or pause. A short proof stage is the cheapest insurance a print run has.
Putting this into practice
Start with a small, real test. Build the batch from a handful of rows, generate the codes, and print them at the exact size and on the exact material you plan to use. Scan each code with two different phones in the lighting where the shelf label will live, and confirm that the destination, the printed text, and the layout all match the brief. Fix anything that fails in the source file or the layout, then re-test, because a fix that is not re-tested is only a guess. Once the small test passes, run the full batch from the same checked inputs, and keep the source file, the proof, and the print file together so a reprint uses the same approved version.
Common mistakes to avoid
The most common mistakes in bulk shelf labels are easy to avoid once they are named. Generating codes from an uncleaned file produces duplicates, broken destinations, and wrong names. Crowding the quiet zone with text, borders, or cut marks makes codes fail even when the print is otherwise good. Printing the full run before testing a proof turns a small fix into a large reprint. Using a long payload on a small shelf label makes modules tiny and hard to read. Skipping a second phone test hides failures that only appear on some devices. Review each of these points on the proof copy, and treat any failure as a reason to adjust the file, the size, or the material.
Quick checklist
- Confirm every row has the right destination and a unique identifier where one is needed.
- Keep payloads short and put readable details in the printed text around the code.
- Leave a clear quiet zone on all four sides of every symbol.
- Print a proof at the final size on the final material and scan it on two phones.
- Check the first and last items on every sheet or batch for alignment and drift.
- File the source data, the proof, and the print file together with a dated note.
Related tools and guides
- Generate the batch with the [retail QR suite](/retail-qr-suite) and check the output before printing.
- Validate every destination with the [QR batch validator](/qr-batch-validator) so broken or duplicate URLs are caught early.
- Package the finished files with the [QR ZIP packager](/qr-zip-packager) so print gets one tidy handoff with a manifest.
- Build the source list with the [bulk generator](/bulk-generator) when the batch starts from pasted rows.
- Size the printed code with the [QR size calculator](/qr-size-calculator) for the real scan distance.
- Test every proof with the [QR scanner](/qr-scanner) on more than one phone.
- Check proofs on paper with the [printed QR tester](/printed-qr-tester) before the full run.
