[HN Gopher] Text case changes the size of QR codes
       ___________________________________________________________________
        
       Text case changes the size of QR codes
        
       Author : ibobev
       Score  : 152 points
       Date   : 2025-11-01 23:34 UTC (5 days ago)
        
 (HTM) web link (www.johndcook.com)
 (TXT) w3m dump (www.johndcook.com)
        
       | mrasong wrote:
       | First time learning about this detail.
        
         | degrees57 wrote:
         | Same. I am thankful that this sort of article shows up here.
        
       | future10se wrote:
       | A similar article was posted earlier this year, discussion here:
       | https://news.ycombinator.com/item?id=43149077
        
       | zygentoma wrote:
       | 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.
        
         | Etheryte wrote:
         | Urls can include parameters and for those capitalization can
         | definitely matter.
        
         | orangewindies wrote:
         | QR codes were created for labelling automotive parts, not for
         | URLs. Part numbers are usually uppercase alphanumeric, with a
         | few punctuation characters.
        
         | mmulqueen wrote:
         | 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.
        
         | vbezhenar wrote:
         | 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.
        
           | Xss3 wrote:
           | Then your qr code only works if the url shortener stays
           | online.
           | 
           | In many cases its wiser to roll your own permanent shortened
           | urls so you aren't beholden to a third party service.
        
             | vbezhenar wrote:
             | Of course you can roll out your own URL shortener. It's not
             | a problem to buy short domain.
        
       | FinnKuhn wrote:
       | 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
        
         | layer8 wrote:
         | That example URL doesn't work when you convert it to uppercase.
         | ;)
        
           | FinnKuhn wrote:
           | It definitely does when I scan each barcode with my iPhone.
        
             | smallerize wrote:
             | The imgur link is case-sensitive though lol.
        
       | chrismorgan wrote:
       | > _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 51/2
       | bits per character (log2 45 [?] 5.49).
        
         | johndcook wrote:
         | Thanks. Fixed.
        
           | drfuchs wrote:
           | It still says "44 characters" when I click the link.
        
             | johndcook wrote:
             | Fixed again. I missed one. :)
             | 
             | Thanks.
        
         | chrisandchris wrote:
         | > [...] must accept the uppercase path [...]
         | 
         | 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.
        
       | ericpauley wrote:
       | 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.
        
         | jdndbxbcb wrote:
         | According to the article / is not in basic alphanumeric
         | alphabet anyway?
        
           | nemetroid wrote:
           | The article has an off-by-one error. There are _45_
           | characters in the basic alphanumeric alphabet, and  / is the
           | missing one.
        
         | mcdonje wrote:
         | I can't help but interpret that as a clue as to which internal
         | groups hold power over there.
        
           | rafram wrote:
           | Huh?
        
             | mcdonje wrote:
             | 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.
        
               | jonathanlydall wrote:
               | They can redirect from the upper to the lower case URL so
               | that it still looks the way they want.
               | 
               | 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.
        
         | tln wrote:
         | I would not link directly to LinkedIn. They have changed the
         | optimal url many times.
        
       | Theodores wrote:
       | 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.
        
         | dgl wrote:
         | > 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.
        
           | sgarland wrote:
           | I love how dedicated some people are to hacking random things
           | for fun. What a great read!
        
         | fisian wrote:
         | 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
        
         | wongarsu wrote:
         | > 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
        
         | nomel wrote:
         | > particularly if you want them to look pretty.
         | 
         | 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.
        
       | slig wrote:
       | 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...
        
       | OhMeadhbh wrote:
       | 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.
        
         | lifthrasiir wrote:
         | `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).
        
           | fph wrote:
           | Can you mix encodings in a QR code?
        
             | OhMeadhbh wrote:
             | yes.
        
         | craftkiller wrote:
         | Interesting, that means git is violating the URI spec. Quoting
         | RFC 3986:
         | 
         | > [...] 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") [...]
         | 
         | https://datatracker.ietf.org/doc/html/rfc3986#section-3.1
        
       | lifthrasiir wrote:
       | 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.
        
       | MereInterest wrote:
       | 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.
        
         | jagged-chisel wrote:
         | The cool bit is, due to the redirect, you can change the final
         | destination without any more carving.
        
           | gregsadetsky wrote:
           | Redirects going anywhere is super flexible, but is also the
           | unfortunate business model of so many "free qr code
           | generator" sites which end up taking your destination link
           | hostage...! (this just reminds me of that, obv the parent
           | post isn't doing that)
           | 
           | 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.
        
       | jwr wrote:
       | I invested quite a bit of effort into designing URLs for the
       | PartsBox ID Anything(tm) system so that they fit well into
       | optimized QR codes. Uppercasing was one of the tricks, and it
       | makes quite a difference indeed. This is important when you want
       | small and yet easily readable/scannable QR codes.
       | 
       | 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.
        
       | theandrewbailey wrote:
       | Just this week, I was writing a script to generate a UUID, make a
       | QR code of it, and print both on a label. I uppercased the UUID
       | to hopefully make the label more human readable after scratching
       | and scuffing, and noticed the QR code got smaller.
       | 
       | Now I know why.
        
       | efskap wrote:
       | It also changes the number of tokens your LLM works with, e.g. in
       | title case it might treat the capitals as their own tokens.
        
       | gregsadetsky wrote:
       | Similar article on this exact topic, with a bit more detail on
       | the QR encoding side, from Terence Eden:
       | 
       | 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
        
       ___________________________________________________________________
       (page generated 2025-11-07 23:01 UTC)