Back to Blog
Guides

QR Codes on Product Labels: What to Put Behind the Code

Aug 31, 202610 min read
QR Codes on Product Labels: What to Put Behind the Code

A product label is the most demanding place you can put a QR code, and almost nothing written about it says why. It is not the design that is hard. It is that you get about a square inch, on a curved surface, under a gloss varnish, competing with text you are legally required to keep — and once the run is printed and the jars are in a warehouse, you cannot take it back. Every other surface forgives you. A label does not.

So this is not a list of clever things to do with a code on a box. It is the three decisions that actually determine whether the code earns its square inch: what it opens, whether you can ever change that, and how to print it so it still scans off a shrink-wrapped bottle in bad shop lighting.

Decision one: what does it open?

The default answer — the homepage — is the one to reject first. Somebody holding your product has already bought it or is standing in front of it. Sending them to a page whose job is to explain who you are wastes the only moment of interest the label will ever generate. The general version of this is covered in where should a QR code point; on a label it is sharper, because you know something about the scanner you almost never know: they have the physical product in their hand.

That narrows the useful destinations considerably. In rough order of how often they earn the space:

  • The thing that would not fit on the label. Full ingredient detail, sourcing, care instructions, assembly, the size chart, the allergen breakdown, the "what to do if it arrives cracked" answer. This is the strongest case for a code on a label, because it is the only one where the code solves a problem the label itself created.
  • How to use it, shown. A short video or a step-by-step for anything where the first two minutes decide whether the customer likes it — a coffee grind, a hair product, a piece of flat-pack furniture, a supplement.
  • Reorder. Consumables where the moment of running out is the moment of highest intent, and the packaging is the only thing in the room.
  • Registration or warranty, for anything with a serial number and a support relationship.
  • A review ask — but only where the packaging survives past first use. A code asking for a review of a product nobody has used yet is asking for a review of a box, which is the exact failure covered in QR codes for reviews and feedback.

One code, one destination. The instinct to give the label a code for the ingredients, another for the recipe and another for the socials is the instinct to make all three too small to scan. If you genuinely have several destinations, the code should open one page that holds them — a Smart Destination Page is exactly that shape, and it also means the list can change without the label changing.

Whatever you choose, it has to work on a phone held one-handed in a shop or a kitchen, and it has to work over a bad connection. And it does not replace anything the label is required to carry. Labelling rules differ by product and by market, and they are not this site's rules to interpret — but the safe assumption is that a code is additive, never a substitute for text that has to be on the pack. Check your own.

Decision two: static or dynamic, decided before printing

This is the decision people get wrong, and a label is the surface where getting it wrong costs the most.

A static code encodes the destination directly in the pattern. It is free, it needs no account, it works forever, and it can never be changed. A dynamic code encodes a short address that redirects, so you can re-point it later — at the cost of a dependency on the redirect continuing to exist.

Now apply that to a print run. Ten thousand labels are not a website. They are a decision you have already made, sitting on a pallet. If the page moves, the campaign ends, the product is reformulated, the video is replaced or the URL structure changes, a static code on those labels is permanently wrong and the only fix is a reprint. A label often outlives the marketing that produced it by years — a jar of jam bought today might be opened next winter.

There is a middle path worth knowing about, and it is the one used for long-lived asset tags: encode a static code pointing at a path on a domain you own — something like yourbrand.example/p/rose-jam — and re-point that path on your own server whenever you like. You keep the flexibility without depending on anybody's redirect service. It costs you a route on your own site, which for a brand that already has a site is nearly free.

The rule that falls out of all three options: the more copies you print and the longer they live, the less the destination should be baked in. A code on a limited-run label for one season can be static. A code on standing packaging should be re-pointable, one way or another.

Decision three: printing it so it survives a shop shelf

Most QR codes that fail on products do not fail because of the code. They fail because of the printing, and label printing has failure modes that a business card never encounters.

Size

Keep it to at least 2cm — about three-quarters of an inch — across the pattern itself. A code scans from roughly ten times its own width, so 2cm gives you about 20cm of range, which is right for a product held in the hand. Going smaller to fit the artwork is the single most common mistake on a label, and it is invisible until the run is printed.

The way to buy back space is not to shrink the code. It is to shorten what you encode. Fewer characters means fewer modules, which means each module is physically larger at the same overall size. A short path on your own domain prints far more robustly than a long tracking URL with parameters hanging off it.

The quiet zone

The blank margin around the pattern is part of the code, not padding. Scanners use it to find the edges. On a crowded label it is the first thing a designer reclaims and the first thing that breaks the scan. Leave it, and never let artwork, a border or a fold bleed into it.

Curves, seams and shrink sleeves

A code wrapped around a bottle is being read at an angle no flat test predicts. Keep it on the flattest available panel, keep it away from the seam, and on anything cylindrical narrower than about 6cm assume the readable arc is smaller than you think. Shrink sleeves distort the pattern during application — that distortion is not uniform, and it is not something you can compensate for in the artwork. Test the sleeved bottle, not the flat proof.

Gloss, varnish and foil

A spot varnish or a gloss laminate over the code turns it into a mirror under shop lighting, and a phone camera sees the light fixture instead of the pattern. Matte-finish the code area if the process allows it. Never print the pattern in metallic ink or foil.

Contrast and colour

Dark pattern on a light background, always. An inverted code — light pattern on a dark label — is out of spec, and plenty of phone cameras simply will not resolve it. A brand-coloured code can work if it is genuinely dark, but "genuinely dark" is a measurement, not an opinion. QR code design that still scans covers where the line actually sits.

Print process

Flexo and thermal both gain: the ink spreads, the light modules narrow, and a code that is fine on a laser proof can close up on the press. Ask the printer to run the code at the final size on the final substrate, and give it a slightly higher error-correction level if it is going onto anything textured or uncoated.

The only test that counts

Scan the printed label. Not the PDF, not a laser proof, not the screen. Scan the real thing, on the real substrate, on the real product, in shop lighting and in a dim kitchen, with a three-year-old phone rather than yours, at arm's length, with the label curved as it will actually sit. Every failure described above is invisible on a monitor and obvious on a shelf.

One code per product, per batch, or per unit?

Per product — one code per SKU — is the right answer for almost everybody, and it is what the product packaging template is built for. It is one destination to maintain and one code to test.

Per batch is worth it only if the destination genuinely differs by batch: a harvest date, a roast date, a lot-specific certificate. That means a page per batch, forever, which is a real content commitment.

Per unit — a different code on every individual item — is where honesty matters more than enthusiasm. This site does not do per-unit serialisation. There is no unit register, no batch tracking, no GS1 Digital Link support and no authentication feature. Bulk generation from a CSV exists on the Business plan, but the codes it produces are static: they are not re-pointable and they carry no scan history, so they suit printing a sheet of one-per-item codes you already know the destinations for, and they do not suit a traceability system. If per-unit traceability is what you need, you need a product built for it, and a QR generator is not that product.

Printing the labels themselves

For short runs — a market stall, a first hundred jars, a pop-up, samples going out to buyers — you do not need a commercial print run. The label sheet generator here lays codes out for standard Avery sheets: Avery 5160 at 30 labels per sheet (2.625 × 1 inch) and Avery 5163 at 10 per sheet (4 × 2 inch), plus a custom size, exported as a print-ready PDF with the product name, SKU and code positioned on each label. It is a Pro-plan feature. On the free plan you can still generate and download a single code as a PNG and place it in your own artwork.

If you are going to commercial print, export the code as SVG rather than PNG — a vector scales to any label size without softening the module edges, and soft edges are what push a marginal code over into unreadable. SVG and PDF export are also Pro features; the pricing page has the full split.

What the scan count will and will not tell you

Scan analytics tell you a code was scanned: how many times, roughly when, roughly where, on what kind of device. On a product label that is genuinely useful for a few narrow questions — whether the code is being used at all, whether interest continues after launch, whether one retailer's shelf performs differently from another's.

It will not tell you who scanned, whether they read the page, whether it changed their mind, or whether they bought anything. A scan is an act of curiosity, not an outcome, and the moment a scan count gets treated as a sales figure it starts producing confident wrong answers. How to track QR code scans covers what the number actually is.

The one comparison it is genuinely good at is your own surfaces against each other. Give the label a different code from the shipping box and from the insert card, and the counts answer a question nothing else can: which physical thing actually gets somebody to lift a phone.

The short version

  • Never the homepage. The scanner is holding the product — open the thing that would not fit on the label.
  • One code, one destination. If you have several, point at one page that holds them.
  • A code is additive to required on-pack text, never a replacement for it.
  • Decide static or dynamic before the artwork goes to print. A pallet of labels cannot be recalled.
  • Best of both: a static code pointing at a path on a domain you own, re-pointed on your own server.
  • 2cm minimum. Buy space by shortening the URL, never by shrinking the code.
  • The quiet zone is part of the code. Do not let artwork into it.
  • Matte the code area, keep it off seams and curves, and never print it in foil or metallic ink.
  • Ask the printer for a proof on the real substrate — flexo and thermal both gain.
  • Scan the finished product, in bad light, on an old phone. That is the only test that counts.
  • Per-SKU suits almost everyone. Per-unit traceability is not something this product does.

Ready to create beautiful QR codes?

Make your own in 30 seconds — no signup required to try.