Why short links make better QR codes
A QR code grows based on how many characters it encodes. Paste in a long link, get a dense grid with tiny squares. Encode a short link instead, get fewer, bigger squares. A QR code based on a shorter link will scan better on smaller surfaces, from farther away, in worse light, or when damaged. Plus, it looks much cleaner to the eye.
A QR code is a grid, and the grid grows
Every QR code is a square grid of black and white squares called modules. The smallest is 21 modules across; the biggest possible is 177. The more characters a code has to encode, the bigger the grid it will need. A 177-by-177 QR code could encode a ton of information, but it would also look extremely cluttered and need to be printed on a huge surface.
Here is the same final link destination encoded in two ways. On the left, a typical campaign URL pasted into a QR code generator as-is. On the right, its 1QRL short link.
Notice that the long URL needs a 53 × 53 grid, while the short link only needs 25 × 25. That's more than a 50% savings in each direction.
Bigger modules scan from farther away
A phone camera has to resolve each module to successfully read a code. Bigger modules can be resolved from farther away, in dimmer light, out of focus, at an angle, or on a curved surface. A dense code needs all of those conditions to be good; a sparse code still works when some are bad.
This difference allows you to print a code in a smaller space, or allows it to be scanned from farther away if it's printed at the same size. How big to print a QR code can help you work out the numbers either way.
What error correction costs
QR codes have built-in error correction. They carry extra data by design, so that they still scan when part of the code is scuffed, dirty, or covered. There are four levels of error correction: L recovers approximately 7% of the code, M around 15%, Q about 25%, and H up to 30%. The extra data takes up modules, though, so every step up in error-correction ability usually makes the whole grid bigger.
1QRL uses M, a good balance for print and the most common default. When you add a logo, it covers the middle of the code, so 1QRL switches to H to make up for the hidden modules. That costs a bigger grid, and it costs a long URL far more:
| Encoded | Level M | Level H, with a logo |
|---|---|---|
| 1QRL short link | Level M25 × 25 | Level H, with a logo29 × 29 |
| Long URL, as-is | Level M53 × 53 | Level H, with a logo69 × 69 |
A short link with a logo is still a much smaller grid than the long URL without one.
Do custom slugs make the code bigger?
A little, and only past a certain point. Randomized short links from 1QRL are 6 characters. An intentionally longer slug adds characters, which eventually takes a bigger grid.
1QRL is able to keep that point farther off than most by encoding every short link in all capital letters, and making the URL case-insensitive. There are why this works better, but the numbers should speak for themselves:
| Slug length | In capitals, as 1QRL encodes it | In lowercase |
|---|---|---|
| 6 characters (generated) | In capitals, as 1QRL encodes it25 × 25 | In lowercase25 × 25 |
| 12 characters | In capitals, as 1QRL encodes it25 × 25 | In lowercase29 × 29 |
| 20 characters | In capitals, as 1QRL encodes it25 × 25 | In lowercase29 × 29 |
| 32 characters (the longest allowed) | In capitals, as 1QRL encodes it29 × 29 | In lowercase33 × 33 |
Even the longest custom slug makes a far smaller code than a pasted URL.