How to shorten a URL before making a QR code

What shortening buys, in numbers

Payload length sets the code's version, and version sets how small each module gets at a fixed print size — the mechanics are in why longer URLs make denser codes. A worked example at error correction M:

Encoded	Length	Version	Grid	Module at 3 cm print
https://example.com/campaigns/2026/spring/landing-page?src=pr	78 chars	5	37 × 37	0.81 mm
https://ex.co/s26 style short link	28 chars	3	29 × 29	1.03 mm

Same destination, 27% larger modules — which is the difference between marginal and comfortable on small print, glossy stock or fabric. Check your own numbers in the size calculator.

Two honest qualifiers before you shorten anything:

• Screens don't care. On a web page or slide, encode the full URL; density costs nothing there.
• Only URLs shorten. WiFi, vCard and payment payloads are not links; a shortener has no role in them.

The dependency you are signing up for

A shortener puts someone else's domain in your ink, permanently. Every scan for the life of the print resolves through them, which means their uptime, their business model, and their policy decisions are now part of your poster:

• Google retired goo.gl, and its short links stopped resolving in 2025 — codes built on them died in the field regardless of how healthy the destinations were.
• Commercial shorteners tie links to accounts and plans; a lapsed subscription can mean broken links or interstitial pages — the failure pattern is documented in link shortener expired, and the general species of risk in what happens when a QR service shuts down.
• Random shortener domains also look untrustworthy: a wary user deciding whether to tap xyz1.io/8fk2 has no signal, which cuts against everything in checking a code before opening.

For a two-week campaign, a reputable shortener is fine. For packaging, signage or anything with years of life, it is the wrong trade.

The better version: short path on your own domain

You can have the density win without the dependency:

Code encodes:  https://example.com/s26      (26 chars — version 2 territory)
Your server:   301 → wherever it should go this season

A rewrite rule or a dozen lines of redirect config gives you a link that is short, branded, trustworthy, permanently yours — and re-pointable, which is the feature dynamic-QR products charge for. Setup patterns (including per-placement paths and UTM injection at the redirect) are in tracking scans without a paid tool; the UTM density interplay is in adding UTM parameters. If you don't yet own a domain, a shortener with an exit plan beats nothing — but a domain costs little and removes the whole risk class.

Whichever you encode, generate it with the URL generator and decode-check the final artwork in the validator — shortened links are especially easy to typo and impossible to eyeball.

FAQ

Does shortening a URL really make a QR code easier to scan?

At print sizes, yes. Fewer characters mean a lower version and physically larger modules — a 78 to 28 character reduction grows modules by about 27% at the same printed width, which is real margin on difficult surfaces.

What happens to my QR code if the shortener shuts down?

Every printed code breaks, even though your destination is fine. This happened at scale when goo.gl links stopped resolving in 2025. The code encodes the shortener's domain, so its fate is the code's fate.

Should I use bit.ly for QR codes?

For short-lived, low-stakes campaigns a reputable shortener is acceptable. For anything printed with a long life, put a short path on a domain you control instead — same density win, no third party in the loop.

Is a shorter URL always better in a QR code?

For print density, yes; on screens it makes no difference. Balance it against readability — a person deciding whether to open the link can judge example.com/menu, but not a random-string short link.