If you sell a physical product, at some point you need sticker sheets with your UPC or barcode on them. Maybe your retailer needs them. Maybe you are switching fulfillment providers and have to re-label old stock. Maybe you just ordered 200 hats and each one needs a scannable sticker before it goes out the door.
The usual approach is painful. You try to set it up in a Word document, or you pay a designer to lay it out in Illustrator, or you find a website that promises label sheets and then delivers something that prints half a centimeter off. By the time you have gone back and forth three times, you have wasted an afternoon and your labels still might not scan correctly.
We ran into this exact problem on a client job: 3 hat products, 50 scannable stickers each, all due at once. Here is the method we used, and why it works reliably every time.
The Problem With Doing It by Hand
There are two separate problems when you try to build label sheets manually, and they trip people up in different ways.
The hand-built way
- Place each barcode image individually in a document
- Hope the barcode graphic is actually correct and will scan
- Guess at the cell size and margin math
- Print a test sheet, find it is off, adjust, repeat
- Redo all of it for the next product or SKU
The generated way
- Put your product name and barcode number in a list
- The barcode is drawn by an authoritative engine that validates it
- Sheet size and label grid are calculated precisely once
- Output is a PDF sized for standard US Letter paper
- Add more SKUs, run it again, done in seconds
The first problem is the layout: getting 50 labels to fit correctly on a standard sheet of paper with the right margins so nothing prints over the edge. That is just math, and once it is right, it stays right.
The second problem is the barcode itself. A barcode is not just a picture. It encodes a specific number in a specific format, including a check digit that scanners use to verify the data is valid. If you use a barcode as a graphic or image without going through an authoritative encoding engine, there is a real chance it will not scan, or worse, it will scan incorrectly and show someone else's product.
How We Generate Them Instead
The method we use solves both problems. For the barcode encoding, we use a JavaScript library called bwip-js, which is the same barcode engine used by professional print and retail tools. It draws the barcode as a vector graphic, validates the number, and computes the check digit. If the number is wrong, it tells you before anything gets printed.
Each product name and its barcode number in a simple list. That is all the input needed.
Draws each barcode as a proper vector, validates the number, and computes the check digit.
Labels are placed in a grid: 5 columns, 10 rows, each cell 1.5" wide by 1" tall, on US Letter paper.
One PDF per product, sized exactly for your printer. Send it straight to print with no further adjustments.
The sheet math works out cleanly for US Letter paper. Each label is 1.5 inches wide and 1 inch tall. Five columns times 1.5 inches equals 7.5 inches, which fits within the 8.5-inch page width when you account for half-inch margins on each side. Ten rows times 1 inch equals 10 inches, which fits within the 11-inch page height the same way. That gives you exactly 50 labels per sheet, edge-to-edge and properly spaced.
The sheet dimensions are calculated once and stay fixed. Every product you add to the list gets the same precise layout. You are not re-measuring anything.
Why the Barcode Engine Matters
This part is worth understanding because it is where most hand-built label sheets go wrong.
A UPC-A barcode, which is the standard retail barcode in the US, is 12 digits long. The last digit is a check digit calculated from the first 11. If you have a barcode image from somewhere and the check digit is off by even one, many scanners will reject it outright. Others will scan it and read back the wrong number. Neither is acceptable on a product you are shipping.
Relative scan reliability by method. The authoritative engine approach is the only one that guarantees a valid barcode before printing.
The bwip-js library is the JavaScript port of BWIPP, Barcode Writer in Pure PostScript, which has been the standard for programmable barcode generation for years. It supports UPC-A, EAN-13, Code 128, QR codes, and many others. You pass it the barcode type and the number. It tells you if something is wrong, and if not, it draws the barcode correctly.
Always do a physical print-and-scan test before you run your full batch. Visual inspection is not enough. Print one sheet, scan the barcode with a real scanner or a scanner app, and confirm it reads back the correct number. That is the only way to be certain.
What This Looks Like in Practice
For the hat job we mentioned, the full process was: three products, each needing 50 stickers on a single US Letter sheet. The setup took a short time to write once. Running it produced three PDFs, one per product, ready to send to the printer. When we needed to make a change to one product, we updated that entry in the list and ran it again. The other two sheets were untouched.
That repeatability is the real win. If you sell 10 SKUs and add 2 more next month, you update the list and run it. You are not rebuilding anything from scratch.
Who This Is For
This is useful for any business that sells a physical product and needs barcodes on it. That includes Shopify store owners labeling inventory, retail brands that need UPC stickers for a new retailer requirement, businesses doing a one-time re-label of existing stock, and anyone who has ever spent too long trying to get a barcode sheet to print correctly.
You do not need to know how any of the technical parts work. You need a list of your products and their barcode numbers. The rest is handled.
At Balay ni Bruno & Co., this kind of work is part of how we support the businesses we partner with. We handle the back-end steps, from building the sheet to running the print test, so the people running the business can focus on the work that actually needs them. It is not a standalone service we sell on its own. It is one of the things that gets done as part of a partnership.
Key Takeaways
- Hand-building label sheets in Word or Illustrator is slow, error-prone, and hard to repeat.
- Barcodes must be generated by a proper encoding engine, not copied as images. An invalid check digit means your barcode will not scan reliably.
- A generated sheet sets the layout math once. Every product after that runs in seconds.
- US Letter paper fits 50 labels cleanly at 1.5" wide by 1" tall in a 5-by-10 grid.
- Always do a physical print-and-scan test before printing the full batch.
Common Questions
Will the barcodes on my label sheet actually scan at the register or with a scanner app?
Yes, as long as you use an authoritative barcode engine instead of a font or a graphic. We use the same barcode engine that professional print and retail tools use. It validates the number and computes the check digit, so the barcode is correct before it ever touches paper. Always do one physical print-and-scan test before running the full batch.
Can I use this for multiple products at once, or do I have to set it up separately for each SKU?
You can do all your products in one run. The setup uses a simple list where you put each product name and its barcode number. The sheet generator loops through the list and produces one PDF sheet per product. Add a new SKU, run it again, done.
Do I need a designer or special software to get print-ready label sheets?
No. The output is a standard PDF sized for US Letter paper, ready to send straight to any printer. No design software needed on your end. The sheet size, label grid, and margins are all calculated so the labels land in the right place every time.