With ascii encoding, this would limit me to 17 characters, but the alphanumeric encoding allowed up to 25 characters. Since DNS is case-insensitive, this let me carve a slightly longer URL. The only downside was that it required making a custom redirect on my own website, since I couldn’t find any url shorteners that would use all caps.
To this day, it is the most effort I’ve put into rick-rolling somebody.
My friend's partner once printed a qr code like that and then had to pay a monthly fee to keep the qr code working. Pure predator behavior.
> 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-.:
This is wrong: alphanumeric has 45 characters, not 44. It’s missing the second last character, /.
(The slash is important because it makes alphanumeric-mode URLs possible: you can write HTTPS://EXAMPLE.COM/PATH which will be parsed to https://example.com/PATH. No query string or fragment due to no ?&=#, and your server must accept the uppercase path, either serving it or redirecting to the lowercase and then serving that.)
An alphabet size of 45 is the largest that will fit into 5½ bits per character (log₂ 45 ≈ 5.49).
FWIW, the path segment itself is case-sensitive and it comed down to the webserver (and then mostly the filesystem) whether it wants to treat the path case-sensitive or not. There's no guarantee in HTTP that /PATH will serve a path located at /path.
It might not be intentional that it doesn’t work with uppercase, but they just made it lower case and by default it’s case sensitive on whatever software stack they use to host.
Later it turned out that when printing labels, you hand your data off to the printer to produce the QR code anyway, and printers do not try very hard to find an optimal encoding.
If you care about QR code size, you should use URL shortener service which you can program in whatever way you need.
So I don't think that's major restriction.
In many cases its wiser to roll your own permanent shortened urls so you aren't beholden to a third party service.
One minor annoyance I have is the ``git`` command line tools (at least the ones distributed w/ Debian) are case sensitive w/ URLs, so if you try the command:
git clone HTTPS://GIT.BI6.US/TQT
git clone https://GIT.BI6.US/TQT
I should probably publish the BASE32 variant we used. Mostly just removed the I's O's and a few other letters that could easily be confused with digits or with other letters.
> [...] schemes are case-insensitive [...] An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") [...]
[1]: https://www.nayuki.io/page/creating-a-qr-code-step-by-step [2]: https://www.brainzilla.com/logic/zebra/pdf/blood-donation.pd...
I want the super succinct QR code and I believe that to be optimal. However, I keep seeing massively complicated QR codes, as if going from 8 bit to 64 bit, and I assume these work well. Given the amount of megapixels in any camera made this century and the prevalence of over complicated URLs in QR form, I am not sure if minimised QR codes have any benefit whatsoever. By minimised, I mean 29 x 29.
On the QR topic, I don't understand how logos in the middle work. You are losing pixels and checks with the logo in the middle which is fine until you make the logo too big.
Also related, imagine you wanted a HN QR code with 'Hacker News' written in the middle. This would work as a box in the middle but would be hard to read. So you can make a line across the middle rather than a box in the middle. This will break the QR code but not if you rotate the QR code 90 degrees first.
Maybe my best option to fully understand the quirks is to start with the QR spec and then to make my own QR codes.
It is possible to add logos without (well, differently) abusing the error correction: https://research.swtch.com/qart
Of course most images in the middle aren’t doing that and rely on some level of error correction fixing it.
It's not just that. It's the resolution of the display device too. It's brightness and whether that is causing bloom. If it's printed small, users may instinctively put the camera too close and it won't be able to focus. People have shaky hands and the image will have motion blur. Glare is a persistent problem with bikeshare apps, where the app turns on your phone's flashlight while scanning for nighttime use, but the QR code is glossy. Codes get scratched up, and the smaller the blocks are, the more they are degraded.
There really are tons of ways QR codes degrade no matter how many megapixels you have, and smaller codes are always going to be more resistant given the same overall physical size.
I've been amazed at some of the QR codes I've seen in TV ads. Multiple subdirectories, plethora of parameters containing full city names and redundant zip codes, etc, resulting in massive QR codes that you can't even use from your couch because they're so dense.
The outside (the parts between the alignment marks) have metadata, separated from the data by a dotted line. If your line touches the metadata that's bad. But as long as you stay within the data block any shape should work as long as you are not modifying more pixels than the chosen level of error correction can handle
https://shkspr.mobi/blog/2025/02/why-are-qr-codes-with-capit...
Past discussion: https://news.ycombinator.com/item?id=43149077
(self promo-ish) The above blog article was one of the pieces shown at the QR Show that I helped co-organize earlier this year at the Recurse Center. I'm definitely tempted to have another one in 2026!
The whole lists of pieces is here: https://qrshow.nyc/retrospective.html
Now I know why.
I tested this with the following example: https://imgur.com/a/hTsvV3Z