How to Create a QR Code From a Short Link (and Track Scans) (2026)

Two rules cover almost everything worth knowing about QR codes:

1. Never encode a long URL. Encode a short link.
2. Never encode a final destination on anything printed. Encode a short link you can redirect later.

Both follow from the same fact: a QR code is a dumb, permanent container. Everything useful — tracking, editing, analytics — has to come from what’s inside it.

I’m Giovanni, and I build ShortLink at Fulin Labs, a free URL shortener that generates a QR code for every link. Most of this post applies to any tool.

Why short links make better QR codes

A QR code’s grid grows with the amount of data it holds. More characters means more modules, and more modules means each one is physically smaller at a given print size.

Compare what you might encode:

https://example.com/products/spring-collection-2026?utm_source=flyer&utm_medium=print&utm_campaign=spring-launch&utm_content=table-tent

versus:

https://s.fulinlabs.com/spring

The first is around 150 characters and produces a dense, fine-grained pattern. The second is about 30 and produces a visibly simpler one. In practice that difference shows up as:

• Scan reliability. Bigger modules tolerate bad lighting, camera shake, cheap phone cameras, and awkward angles. Dense codes fail in exactly the real-world conditions where people scan things.
• Print size. A simple code stays readable on a business card or a table tent. A dense one needs real estate you may not have.
• Damage tolerance. QR codes carry error correction, but coarser modules survive smudges, folds, and printing imperfections much better.
• It just looks better. A clean code reads as intentional; a dense grey square reads as clutter.

If you’re tagging campaigns with UTM parameters — and for print you should be — this stops being a nicety. A fully tagged URL is long by definition, and encoding it directly is close to the worst case. Shorten first, then generate. I covered the tagging conventions in the UTM builder guide.

How scan tracking actually works

There’s a common misconception that QR codes report their own scans. They don’t. A QR code is an encoded string of text and nothing else — no logic, no callback, no reporting.

Scan tracking works by indirection:

1. The code encodes a short link.
2. Someone scans it; their phone opens the short link.
3. The shortener records a click and redirects.
4. That click appears in your analytics.

So scans become clicks. Every piece of data your shortener collects — count, timing, rough geography, device — you now have for your printed material. That’s the entire mechanism, and it’s why “trackable QR code” always means “QR code pointing at a link you control.”

The consequence: if you generate a code from a free QR generator that encodes your destination directly, you get zero data, permanently. The code works; you just have no idea whether anyone used it.

One practical refinement — tag the medium as print or QR. If your poster’s short link carries utm_medium=print, you can separate physical-world traffic from everything else in your site analytics, which is otherwise nearly impossible to attribute.

The editable destination problem

This is the one that costs people real money.

You print 5,000 flyers. The QR code encodes https://example.com/spring-collection. Two months later that page is retired, or the campaign moves, or someone restructures the URL scheme. Every printed flyer now leads to a 404, and there is nothing you can do about it — the pattern is ink on paper.

Encode a short link instead and the failure becomes trivial: change where the short link points, and all 5,000 flyers now work again. Same ink, new destination.

This applies to anything with a lifespan measured in months: packaging, signage, business cards, conference banners, stickers, menus, vehicle livery, book pages. Anything you can’t cheaply reprint should point at a redirect you control. It costs nothing extra and it’s insurance against a category of mistake that’s otherwise unfixable.

Worth checking on your chosen tool: can you edit a link’s destination after creation? Not every shortener allows it, and without that capability the whole argument collapses.

Print mistakes that kill scan rates

Assuming the code itself is clean, most scan failures are physical:

Too small. Roughly 2 x 2 cm is a sensible practical floor for close-range scanning, and bigger is better. Scale with distance: a poster read from three metres needs a much larger code than a business card. If in doubt, print a test and scan it with an old phone.

No quiet zone. QR codes need clear margin around them — a border of blank space roughly four modules wide. Designers routinely crop this to save room, and cropped codes fail to scan for reasons nobody can diagnose by looking.

Inverted colours. Light code on a dark background breaks many scanners. Dark on light. Always.

Low contrast or busy backgrounds. A QR code over a photograph looks sophisticated and scans badly.

Glossy stock under direct light. Glare wipes out sections of the pattern. Matte finishes are meaningfully more reliable for anything that’ll sit under lighting.

No call to action. A bare code gets ignored. “Scan for the menu” or “Scan for 10% off” reliably outperforms a naked square, because people need a reason before they’ll aim a camera at something.

Never test-scanned. Print one. Scan it. With more than one phone. This catches almost everything above and takes two minutes.

A workable process

1. Build the destination URL and tag it — utm_medium=print or qr, plus source and campaign.
2. Shorten it, with a readable custom alias if the link will also appear in text.
3. Generate the QR code from the short link.
4. Print at adequate size, dark-on-light, with the quiet zone intact and a clear call to action.
5. Test-scan a physical proof before the full run.
6. Watch the click data, which is now your scan data.
7. When the campaign ends, repoint the short link somewhere still useful rather than letting the printed material die.

Step 7 is the one everybody skips. Printed codes keep getting scanned for years after a campaign ends, and pointing them at your homepage instead of a dead page is free.

Doing this with ShortLink

ShortLink is free and its current web interface requires an approved account. For this workflow:

• Every link gets a QR code automatically — generated from the short link, so it’s already the low-density version.
• Real-time click analytics with rough geographic origin. Scans appear as clicks, immediately, without a dashboard refresh delay — which matters when you want to know whether the conference banner is working while you’re still at the conference.
• Custom aliases, so s.fulinlabs.com/menu beats a random code on printed material where people might also type it.
• A UTM builder, so the print medium is tagged before you shorten.
• Colour-coded folders, useful when one campaign spans several printed pieces each with its own code.
• A RESTful API for generating codes in bulk — see creating short links via API.

Two honest caveats. ShortLink issues links on s.fulinlabs.com, not your own branded domain, which some print contexts care about. And it also offers link expiration — a genuinely useful feature that you should be careful with on printed codes, since an expired link means a dead flyer. For print, don’t set an expiry.

The short version

Generate QR codes from short links, never from long URLs — the code is simpler, scans more reliably, and prints smaller. QR codes can’t track anything themselves; tracking comes from the link inside, so scans show up as clicks in your shortener’s analytics. Never encode a final destination on printed material, because a redirect you can edit is the only way to fix a campaign after the ink dries. Then print it dark-on-light, big enough, with its quiet zone intact — and test-scan a proof before you order 5,000 of them.