URL QR codes vs short-link QR codes — what changes

The cheapest way to make a QR code is to paste a URL into a generator and download the PNG. It works. It scans. The thing it doesn't tell you is that the URL you encoded is locked into the print forever, and almost any URL you'd realistically encode is too long to make a clean code.

A URL QR code and a short-link QR code can point to the same destination but they aren't equivalent. One is a permanent commitment to a specific URL; the other is a redirect you control. One produces a dense, ugly grid; the other produces a sparse, brandable one. The difference matters every time you reprint and almost never the first time.

This post walks through what changes when you put the URL through a short link first — and the cases where the long URL is actually the right call.

Length is the visible difference#

A QR code's data area scales with how much it has to encode. A 30-character URL fits comfortably in a sparse 21×21 grid. A 90-character URL with UTM parameters needs a 33×33 grid. A 200-character URL with tracking IDs and OAuth state pushes you toward 45×45 — that's a lot of modules to scan.

The decoder doesn't care. The print does. A denser grid means smaller modules at the same physical size, and smaller modules mean less margin against fading, smudges, low light, slightly off-axis scans. Densification is the slow-motion failure mode of unprinted QR codes — they work in the proof, then fail in production at the edges of the run where the press lays slightly less ink.

A short link compresses any URL down to about 17-22 characters: domain plus 6-8 character key. That puts you in a 21×21 grid no matter what the original URL was. You buy back the entire dense-grid problem in one move.

The two costs#

Short-link QR codes aren't free. You're trading two things:

Dependency on the redirect host. The QR encodes lnks.work/k/menu. That short link only resolves while lnks.work is up and the redirect to your real URL is still wired correctly. If the host disappears, the QR codes go with it.

A small added latency. The phone scans the QR, fetches lnks.work/k/menu, gets a 302 redirect, follows it. That extra round trip is usually under 100ms on a healthy host. Users perceive it as instant. You lose nothing visible.

In exchange, you get:

• Editable destination. Change where the QR points without reprinting.
• Sparse, scannable code. Easier to make round, brand, embed.
• Scan analytics. The redirect is a logged event — count, time, country, device.
• Insurance against URL changes. If the destination URL changes (rebranding, new CMS, marketing wants to add a UTM after the fact), the redirect absorbs it. The QR keeps working.

Whether those four wins are worth the two costs depends entirely on what the QR is for and how long it has to stay valid. For consumer-marketing surfaces, almost always yes. For a building plaque etched into stainless steel for the next 50 years, the redirect dependency is the bigger risk.

A density comparison#

That number — 33×33, 41×41, 49×49 — is the practical reality. Every step up makes the modules a touch smaller in the same printed area, and smaller modules age worse.

Densification is the slow-motion failure mode of unprinted QR codes — they work in the proof, then fail in production at the edges of the run where the press lays slightly less ink.

When the URL QR is correct anyway#

A few cases where encoding the URL directly is the right answer:

The URL is already short. https://example.com at 19 characters is shorter than most short-link URLs. There's no density saving to be had. The decision becomes "do I want editability and tracking" — if no, encode directly.

The destination is offline-first or local. A QR code on a museum exhibit pointing at a local Wi-Fi-served page (http://exhibit.local/info) only resolves on the museum's network. A short link wouldn't help.

Privacy / no third party. A QR on a printed report linking to a sensitive doc on your own infrastructure shouldn't go through a third-party redirect. Either your audience trusts the redirect host, or they shouldn't have to.

Print runs intended to outlive any redirect host. A plaque, a stone, a vehicle wrap meant to last 20 years. If you can guarantee the URL itself stays valid (e.g., it's yourdomain.com/exhibit/3, you control the domain, and you'll preserve the redirect rule for the lifetime of the plaque), the URL QR is the safer long-term bet.

For everything else — flyers, posters, table tents, packaging that gets reprinted every quarter, anywhere you might want to repoint — short link wins.

How to migrate a URL QR to a short-link QR#

You can't change the print. You can change what's at the URL.

If your existing QR encodes https://yourdomain.com/old-campaign-page and you want flexibility now, replace the old page with a 301 or 302 redirect to your real destination. From here forward you can repoint the redirect anywhere. You've turned the static URL QR into a pseudo-dynamic one — at the cost of one DNS-level or server-level redirect rule.

The catch: you only have this option if you control the original URL. A QR encoding https://someoneelsesservice.com/abc doesn't give you that escape hatch.

For codes you haven't printed yet, generate them as short links from the start. The dashboard does the work; the print stays the same; you keep the option to change anything later.

What about UTM parameters?#

People paste long URLs into QR generators because they want to keep the UTM tags so analytics knows the traffic came from "poster, autumn campaign". This works but density-tanks the code.

Cleaner approach: the short link absorbs the UTMs. lnks.work/k/menu redirects to https://yourdomain.com/menu?utm_source=poster&utm_medium=qr&utm_campaign=autumn. The QR is sparse. The analytics still get tagged. The UTMs live in the redirect, not the print.

This is the standard trick behind every campaign QR you've seen on a billboard.

What we ship#

Linked.Codes generates QR codes for either kind. By default, when you create a QR code in the dashboard, it's a dynamic short link — sparse code, editable destination, scan tracking. You can override and encode a raw URL if the use case calls for it (vCard, WiFi, building plaque). The code render is the same either way; the encoded payload is what changes.

For a short link, you can pick the slug or accept an auto-generated one. The link lives at your <your-handle>.linked.codes/k/<slug> by default, or your custom domain when you've connected one. If you switch domains later, the dashboard rewrites the link records in place — all your QR codes keep working without reprinting.