This was something that I paid close attention to when designing a QR code to be hand-carved into a set of coasters. To minimize the amount of detail carving required, I wanted to use the smallest QR code at 21x21 (version 1) tiles.
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.
> Alphanumeric data, in the context of QR codes, comes from the following alphabet of 44 characters:
> 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).
A major frustration in my life is that LinkedIn QR codes will not support all caps. It’s not even a profile capitalization issue; the app will refuse to scan the code if the “/in/“ is capitalized. The resulting size difference is quite noticeable particularly in small format.
Lowercase "in" is a major part of their branding. Forcing usage of lowercase "in" in this scenario supports the branding even if it doesn't make sense from an engineering standpoint.
Wouldn't it have been much more sensible to have a lowercase version of alphanumerics in the QR code standard? Almost all URLs are lowercase, and even if the have capitalised parts, in most cases they're case-insensitive.
QR codes were created for labelling automotive parts, not for URLs. Part numbers are usually uppercase alphanumeric, with a few punctuation characters.
QR codes existed for over a decade before smartphones brought them into the mainstream. They're high density replacements for barcodes, which are uppercase by convention (or in some cases like Code 39, only support uppercase). URLs in QR codes are a later innovation.
In the 2010s I had a startup generating a bunch of QR Codes. We generated URLs with a BASE32 variant plus upper case domain and scheme so we could stay within the 5.5 bits per character encoding. I kept trying to explain this feature to people, but it was an uphill battle. To this day I still use upper case w/ URLs JUST-IN-CASE I want to put them in a QR Code.
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
you'll get an error, but
git clone https://GIT.BI6.US/TQT
does what you might expect it to do. This is a very minor nit since no git tool I know directly consumes QR codes and if you made one, you could lower case the protocol section yourself. It's just that all day I'm using URLs that are intentionally upper-cased and the one time I need to lower-case a portion of it, I always forget.
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.
`https://GIT.BI6.US/TGT` is actually not that bad because the optimal encoding will use the 8-bit encoding only for the `https` part and you only need 13 more alphanumeric characters to beat the full 8-bit encoding (if my calculation is correct).
This tool [1] let me figure that out couple of years ago. And on the printable pages of the sites I own, for instance [2], I use a all caps domain and identifiers so that all my QR Codes are tiny (e.g: `HTTPS://ABC.DE/ABCD/42`, with up to 10 chars in the path).
You don't need to make the whole payload uppercase to benefit from this aspect of QR code, as a single QR code can use multiple different encoding schemes. It is sufficient that a large consecutive portion of your payload is limited to those alphanumeric characters.
I am amazed at how much there is to know about QR codes, particularly if you want them to look pretty.
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.
> 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.
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
> 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.
Another fun thing are these stable diffusion/controlnet combinations which create QR codes that at the same are AI generated art. e.g. qrdiffusion or qrbtf
This was something that I paid close attention to when designing a QR code to be hand-carved into a set of coasters. To minimize the amount of detail carving required, I wanted to use the smallest QR code at 21x21 (version 1) tiles.
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.
> Alphanumeric data, in the context of QR codes, comes from the following alphabet of 44 characters:
> 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).
Thanks. Fixed.
It still says "44 characters" when I click the link.
Fixed again. I missed one. :)
Thanks.
A major frustration in my life is that LinkedIn QR codes will not support all caps. It’s not even a profile capitalization issue; the app will refuse to scan the code if the “/in/“ is capitalized. The resulting size difference is quite noticeable particularly in small format.
I can't help but interpret that as a clue as to which internal groups hold power over there.
Huh?
Lowercase "in" is a major part of their branding. Forcing usage of lowercase "in" in this scenario supports the branding even if it doesn't make sense from an engineering standpoint.
According to the article / is not in basic alphanumeric alphabet anyway?
The article has an off-by-one error. There are 45 characters in the basic alphanumeric alphabet, and / is the missing one.
Wouldn't it have been much more sensible to have a lowercase version of alphanumerics in the QR code standard? Almost all URLs are lowercase, and even if the have capitalised parts, in most cases they're case-insensitive.
QR codes were created for labelling automotive parts, not for URLs. Part numbers are usually uppercase alphanumeric, with a few punctuation characters.
QR codes existed for over a decade before smartphones brought them into the mainstream. They're high density replacements for barcodes, which are uppercase by convention (or in some cases like Code 39, only support uppercase). URLs in QR codes are a later innovation.
Urls can include parameters and for those capitalization can definitely matter.
domain name and protocol name is case-insensitive.
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 the 2010s I had a startup generating a bunch of QR Codes. We generated URLs with a BASE32 variant plus upper case domain and scheme so we could stay within the 5.5 bits per character encoding. I kept trying to explain this feature to people, but it was an uphill battle. To this day I still use upper case w/ URLs JUST-IN-CASE I want to put them in a QR Code.
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:
you'll get an error, but does what you might expect it to do. This is a very minor nit since no git tool I know directly consumes QR codes and if you made one, you could lower case the protocol section yourself. It's just that all day I'm using URLs that are intentionally upper-cased and the one time I need to lower-case a portion of it, I always forget.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.
`https://GIT.BI6.US/TGT` is actually not that bad because the optimal encoding will use the 8-bit encoding only for the `https` part and you only need 13 more alphanumeric characters to beat the full 8-bit encoding (if my calculation is correct).
A similar article was posted earlier this year, discussion here: https://news.ycombinator.com/item?id=43149077
This tool [1] let me figure that out couple of years ago. And on the printable pages of the sites I own, for instance [2], I use a all caps domain and identifiers so that all my QR Codes are tiny (e.g: `HTTPS://ABC.DE/ABCD/42`, with up to 10 chars in the path).
[1]: https://www.nayuki.io/page/creating-a-qr-code-step-by-step [2]: https://www.brainzilla.com/logic/zebra/pdf/blood-donation.pd...
You don't need to make the whole payload uppercase to benefit from this aspect of QR code, as a single QR code can use multiple different encoding schemes. It is sufficient that a large consecutive portion of your payload is limited to those alphanumeric characters.
This also seems to work for URLs so next time I will create a QR code I will keep this in mind. Really useful!
I tested this with the following example: https://imgur.com/a/hTsvV3Z
That example URL doesn’t work when you convert it to uppercase. ;)
It definitely does when I scan each barcode with my iPhone.
First time learning about this detail.
Same. I am thankful that this sort of article shows up here.
I am amazed at how much there is to know about QR codes, particularly if you want them to look pretty.
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.
> 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.
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
> 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.
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.
I love how dedicated some people are to hacking random things for fun. What a great read!
Another fun thing are these stable diffusion/controlnet combinations which create QR codes that at the same are AI generated art. e.g. qrdiffusion or qrbtf