Almost everything written about QR codes is about the square: how big, what colour, how much error correction, whether the logo in the middle breaks it. All of that matters and none of it is the product. A QR code is a container for a URL. The person scanning it spends about half a second on your square and the rest of their attention on the page it opened — a page you chose. That choice is the whole thing, and no amount of design rescues a bad one.

This is the decision that comes before the ones in QR code design that still scans and what to put next to a QR code. Get it wrong and those two cannot help you.

Do not point it at your homepage

This is the most common destination and it is almost always the wrong one, for a reason worth being precise about: a scan carries context that a homepage immediately discards.

Someone scanning a code on a shelf edge is standing in front of one product. Someone scanning a table tent has already sat down. Someone scanning a leaflet has just been handed it by a person. In each case you know something specific about what they want — and a homepage answers by presenting them with every option you have, including the ones they have already ruled out by being where they are. You have converted a specific question into a menu.

The rule that follows is simple: the destination should be the answer to the question the person was asking when they scanned. One code, one product page. One code, one menu. One code, one signup form with the event already filled in. If you cannot name the question, you do not yet know where the code should point, and printing it will not tell you.

There is one honest exception. When a surface genuinely offers several unrelated things — a poster for a venue that has a menu, an events calendar and a newsletter — a single code pointing at a small page that lists those three beats three codes competing on the poster. The decision still gets made, but it gets made on a screen where the person can read at their own pace.

The page has to work for someone standing up

A scan almost never happens at a desk. It happens standing in a shop, sitting in a restaurant, walking past a window, waiting in a queue, holding a bag in the other hand. That rules out more than people expect:

A PDF is not a landing page. It opens in a viewer, it does not reflow, and reading it means pinching and dragging around a document sized for A4. This is the single most common failure behind restaurant menu codes, and it is covered in more detail in QR codes for restaurants.
Anything requiring typing is a wall. One-handed typing on a phone while standing is genuinely difficult. A destination that opens with an email field has asked for more than the scan was worth.
A login wall ends it. Whatever is behind the code, some usable version of it has to be visible before an account exists.
A slow page is a broken page. The person is standing still in public waiting for you. That is a much shorter fuse than the same page opened on a sofa.

The test that catches nearly all of this: open the destination on your own phone, standing up, one-handed, on mobile data rather than office wifi. Most bad destinations fail that test in the first three seconds.

The length of the URL changes the code

This one surprises people, and it is the most concrete link between the destination and the square. A QR code encodes the characters of the URL. More characters means more modules — the little squares — packed into the same area. A denser code needs either more physical space or better scanning conditions to read reliably. So a long URL literally makes your code harder to scan at the same printed size.

Where that bites hardest:

Small print surfaces. A business card, a bottle neck label, a shelf tag. There is a fixed amount of room, and a long URL spends it on density instead of margin.
Anything read at distance. A code sized for a banner is already fighting the physics; adding characters makes it worse.
Anything with a logo in the middle. The logo occupies modules that error correction has to cover for. A dense code has less slack to give.

This is also why printing the URL underneath the code — which you should, for the reasons in are QR codes safe — argues for a short one. A destination you cannot print in small type under the square, or read aloud over a phone, is too long. The physical-size and error-correction constraints are set out on the design studio page.

Where campaign parameters fit

Tracking parameters appended to a URL — the utm_ family and their equivalents — are a legitimate way to tell your web analytics that a visit came from a particular piece of print. They also make the URL substantially longer, which is exactly the problem above, and they make it unprintable and unspeakable.

The honest trade-off: if your analytics live on the destination site and you need the visit attributed there, parameters are how that is done. If what you actually want to know is "is this poster being scanned", a code whose redirect is counted separately gives you that without putting a single extra character in the printed payload. How to track QR code scans sets out what each approach can and cannot tell you — and what neither can.

Short links and dynamic codes are not the same tool

These get conflated constantly, and choosing between them is really choosing what you want to be able to change later.

A short link is a URL that is deliberately brief, so it can be printed, typed, read out on a podcast or fitted into a character limit. Its value is that a human can handle it. It happens to also be shorter to encode.
A dynamic QR code is a code whose encoded address is a redirect you control, so the destination can be changed after the code has been printed. Its value is that the artwork stops being a permanent commitment.

They overlap — both put an indirection between the printed thing and the final page — but the reason to reach for each is different. If your problem is "this URL is too ugly to print", that is a short link. If your problem is "this poster will be on a wall for two years and the campaign behind it will not last that long", that is a dynamic code. If both are true, one indirection can serve both purposes; there is no reason to stack two.

The cost of either is the same and it is worth stating plainly: you have introduced a dependency. The printed code no longer contains the destination — it contains an address that has to keep resolving. Static vs dynamic QR codes goes through what that means and when the trade is not worth making.

Assume the destination will die

Print outlives web pages, and it is not close. A leaflet sits in a drawer. A sticker stays on a laptop. A plaque stays on a wall for a decade. Meanwhile the page it points at survives one site redesign, maybe two, and then becomes a 404 — or worse, silently redirects to a homepage, which looks like it works and is the failure described at the top of this page.

Two things make that survivable, and they are cheap if done at print time rather than afterwards:

Point at something structural rather than something temporary. A product page outlives a campaign page. A section outlives a single post. If the only honest destination is temporary, that is the strongest possible argument for a dynamic code.
Decide now what the code should do when the thing it advertises is over. A code for a closed event should go somewhere useful, not to an error. That decision is free to make in advance and awkward to make in a hurry six months later.

Sometimes there should be no destination at all

Not every QR code needs a URL, and reaching for one by reflex creates a network dependency where none was required. A code can carry its whole payload:

Wifi credentials, so a guest joins without typing a password.
A contact card, so a phone saves a name, number and email directly.
Plain text, for a serial number, a reference, or an instruction.

All three work with the phone in aeroplane mode, which matters more than it sounds: lift lobbies, basements, rural sites and the inside of large venues are exactly where codes get placed and exactly where a page will not load. If everything the person needs fits in the code, put it in the code.

The short version

Never the homepage. Point at the answer to the question the scan implies.
Open it on your own phone, standing up, on mobile data. No PDFs, no typing, no login wall.
Keep the URL short — length makes the square denser and harder to scan at the same size.
Campaign parameters go on the destination, not into the printed payload, unless you specifically need them attributed on the destination site.
Short link ≠ dynamic code. One is for humans handling the URL; the other is for changing your mind after printing.
Plan for the page to die, and decide in advance where the code goes afterwards.
If the payload fits in the code, skip the URL entirely.