QR Codes for Print Marketing: Placement, Size and Tracking

QR codes on printed material fail for boring reasons. The code is too small for where it's placed. It's on something people can't stand still in front of. It encodes a long URL that's dense and fragile. And when it does get scanned, nobody can tell, because the destination is the same page the website links to and the scans vanish into "direct traffic". None of those problems are about QR codes as a technology; they're about placement, size and measurement, and each has a simple fix.

This guide covers the fixes in the order you'll meet them: deciding where a code goes and how large it must be there, what to encode (a short link, always), how to measure visits per placement, and the production details that separate a code that scans first time from one that makes people give up.

Where QR codes get scanned, and where they don't

A QR code is scanned by someone who has a phone in hand, a few seconds, and a reason. Design around those three.

Places where all three are true:

• Restaurant tables, café counters, bar tops. People are seated, waiting, and want the menu; they expect a code here.
• Packaging, labels, receipts. The product is in their hand; the code offers instructions, registration, a reorder.
• Event signage, name badges, conference stands. Attendees are there to collect things; a code to a deck, a demo or a contact is expected.
• Print advertising in waiting situations — transit interiors, waiting rooms, in-flight magazines. Captive time.
• Direct mail. Held in the hand, read at home.

Places where at least one is false:

• Billboards on roads. Nobody scans from a moving car, and they shouldn't. If you must, make it enormous and aim it at pedestrians.
• Moving vehicles. Same.
• Anything at ceiling height or behind glass with reflections.
• TV and video — briefly on screen, at a distance, gone. A short spoken URL beats a code here.

The rule of thumb: if a person can stop, face the code squarely at under two metres and hold their phone steady for two seconds, it can be scanned. Otherwise it's decoration.

How large to print it

Size follows scan distance. A common starting heuristic is a code width of about one tenth of the distance it's scanned from; more for dense codes or poor light. It isn't a guaranteed minimum: module density, print quality, the phone's camera, contrast and light all change what works, so treat the sizes below as a place to start and test.

Two things raise the size you need:

• Data density. A code holding a 90-character tagged URL has far more modules (the little squares) than one holding go.you.com/menu, and each module is smaller for the same overall size. Encoding a short link makes the code sparser and easier to read at every size — which is the first reason to always encode a short link.
• Print quality. Newsprint, fabric, curved surfaces and low-contrast colour all need a larger code than glossy card.

Print the code, put it where it will live, step back to the real distance, and scan it with the oldest phone in the office. That test costs nothing and catches most failures.

What to encode: a short link, every time

The code should hold a short link on your domain, not the destination URL. Three reasons, each sufficient on its own.

1. You can change where it goes after printing

The pattern on the paper never changes. A short link's destination can be edited at any time. A menu code that points at go.cafe.com/menu shows the September menu today and the October one next month, on the same printed cards. A code that encodes cafe.com/menus/september-2026.pdf is wrong on the first of October and stays wrong until you reprint. Editable destinations are the main reason to put a shortener behind print at all.

2. The code is smaller and more robust

Fewer characters means fewer modules means a code that scans from further away, on worse paper, with a worse camera. A URL with UTM tags on it can more than double the module count.

3. Visits are counted, per placement

A code that encodes the destination directly sends scans into the destination's "direct" traffic, indistinguishable from someone typing the address. Opening a code that encodes a short link is a request the shortener counts — with time of day, country and device — and if each printed placement has its own short link, you learn which placements work. That's the next section.

You get the tracking without any tags visible to the reader: the short link's destination can carry UTM parameters without them appearing in the printed link, so your site analytics also see "print / flyer / spring-2026".

Measuring visits per placement

The method is the one that works for every channel: one short link per placement. The flyer gets /spring-flyer, the table cards get /menu-table, the window poster gets /spring-window, the packaging gets /setup-box. Same destination, different links, and now each code's visits are their own number. A visit is counted when the phone opens the short link, not when the camera merely recognises the pattern, and someone who types the printed link counts towards the same number — which is fine, because it's the same placement.

On Xlyl's statistics page each link shows its clicks by hour and day, the country, region and city of each visit, and the device. For print, the hourly chart is unusually informative: you'd expect table-card visits to cluster around meal times; a poster in a station peaks with commuter hours; a code in a monthly magazine trickles for weeks. The device split tells you what the code was scanned with, which matters for how the destination should be built (almost entirely phones, so the landing page had better be fast and mobile-first).

Known bot traffic — link previews, mail scanners that identify themselves — is filtered by user agent before counting, so the count is visits through that link, not a head count. Counting needs an account: links made without one aren't counted. Each visit keeps its location and device; visitor IPs are never stored.

Generating the code is one click on any link in the dashboard: the QR code generator shows a code that encodes the short link, with buttons to download it as SVG (sharp at any print size) or PNG, so the code, the link and the count are one object. The downloaded image already includes a four-module quiet zone; keep it when you place the code in your layout.

Production details that decide whether it scans

Quiet zone

The code needs a margin of blank space on all four sides — at least four modules' width, more is safer. Designers routinely crop it to fit a layout, and the code stops scanning. Treat the quiet zone as part of the code.

Contrast and colour

Dark modules on a light background. Black on white is safest; a dark brand colour on white or cream is fine; anything inverted (light on dark) fails on many readers, and low-contrast pairs (mid-grey on white, two mid-tones) fail on most. If the code sits on a photograph, put it in a white box.

Error correction

QR codes carry redundancy so they scan when partly obscured. The four error-correction levels are part of the ISO/IEC 18004 standard and can restore roughly 7%, 15%, 25% and 30% of the code's codewords (its blocks of data). That isn't permission to cover that share of the printed image: the three corner squares and other structural patterns have to stay readable. Higher levels (Q, H) survive more scuffing, at the cost of more modules. Xlyl's codes use level L, the lowest, which keeps them sparse, and have no logo option. If you put a logo on a code made elsewhere, use a high level, keep the logo small and off the corner squares, and don't rely on any percentage: scan a printed proof.

Surfaces

Flat, matte, opaque. Glossy laminate reflects the phone's flash; curved bottles distort the pattern; fabric blurs it; glass adds reflections. If the surface is unavoidable, go a size up and test on the real thing.

Say what it does

Put a line of text beside the code: what the reader will get, and the short link itself in words — "Scan for the menu · go.cafe.com/menu". The text gives non-scanners a way in, tells scanners what they're about to open, and doubles as the fallback if the code is damaged. It's also why the alias should be short and readable.

Where the scan lands

Everything above is wasted if the destination is slow or built for a desktop. Nearly every scan comes from a phone, often on mobile data, often outdoors. The page must load fast, fit the screen, and do the one thing the code promised. If the destination is a PDF, keep it small. If it's a form, keep it short.

And because the short link can be edited, you can fix a bad landing page after the print run — which, in practice, is the QR feature people end up most grateful for.

A checklist before the print run

1. Is the code somewhere a person can stop, face it, and scan within two seconds?
2. Is it about one tenth of the scan distance wide, as a starting point — and a size up for poor paper or light?
3. Does it encode a short link on your domain, not the destination?
4. Does each placement have its own short link?
5. Quiet zone intact, dark on light, and any logo small, off the corner squares and tested?
6. Is the short link printed in words beside it?
7. Have you scanned a printed proof, at the real distance, with an old phone?
8. Does the landing page load quickly on a phone?

Eight yeses and one test scan is all it takes.

Related guides

• Custom short link best practices: naming and organising
• Track marketing campaigns with short links (UTM guide)
• How URL shorteners work
• QR code generator · Custom domain setup