About decimal encoding in QR codes

Huon Wilson wrote an article titled 10 > 64, in QR codes, about using decimal encoding to reduce QR code density.

The article mentions that a QR code can contain segments in different “modes”, such as numeric, alphanumeric, binary and kanji. I didn’t know that! I had assumed that the entire QR code had to use the same mode.

Something I keep returning to is that if a QR code encodes a case-insensitive URL, you can reduce the density by storing it as uppercase, thereby enabling the use of the alphanumeric mode instead of the binary mode. Since the protocol part (https://) and domain name part (www.example.com) are always case-insensitive, it might be possible to encode some URLs more efficiently even if the rest of the URL is case-sensitive.

Hairdresser sign

  • Size: 33×33
  • Version: 4
  • Error correction: Q
  • Mode: binary
  • Contents: HTTP URL with short path (35 characters)

This QR code leads to a page for installing a smartphone app for booking hairdresser appointments. The path is case insensitive (the server returns the same page if you try to access the URL in all uppercase), so this QR code might equally be encoded in alphanumeric mode. The resulting new code would be  a version 3 code, with a size of 29×29 modules, while keeping the same error correction level:

Infrastructure project sign

  • Size: 29×29
  • Version: 3
  • Error correction: Q
  • Mode: binary
  • Contents: HTTP URL without path (26 characters)

As this URL only consists of the HTTP protocol specifier and a domain name, both of which are case insensitive, we can drop down to alphanumeric mode without hesitating. Keeping the same error correction level, that would result in the following version 2 code, with 25×25 modules:

 

Dental clinic advertisement

  • Size: 61×61
  • Version: 11
  • Error correction: M
  • Mode: binary
  • Contents: MECARD with physical address, email address, phone number and website URL (216 characters)

This QR code, while more complex (and thus more difficult to scan) than usual ones, contains a lot of information. A mobile phone would probably suggest creating a contact entry out of this data, which would then give you easy access to sending emails, making phone calls, and even looking up the location on a map.

Thus, encoding the data in alphanumeric mode, thereby forcing it to be all uppercase, would probably not be a good idea. The resulting code would still be fairly big at version 8, and putting the name of the clinic and the postal address in uppercase would not look very good. A possible optimisation would be to leave out the address, which takes up almost half of the space.

 

Tea bag tag

  • Size: 25×25
  • Version: 2
  • Error correction: M
  • Contents: HTTP URL to a link shortening service that requests access to location data (18 characters)

As the link shortening service uses case sensitive paths, there is no simple way to move to alphanumeric encoding. Presumably, if the link shortening used only uppercase letters, the addresses would be correspondingly longer, and we would likely end up more or less where we started.

Besides, this code is at version 2 already, and version 1 codes may in some cases be harder to scan, since they lack the extra alignment pattern. Thus I conclude that there is not much opportunity to improve this QR code.

Follow us on social media

Three in one. The top one is very dense, and the six alignment patterns (as opposed to the usual single one) stand out.

  • Size: 53×53
  • Version: 9
  • Error correction: Q
  • Contents: HTTP URL with path and the following query string: goback=%2Efcs_GLHD_reed+_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2&trk=ncsrch_hits

Because of the query string, this URL takes 110 bytes instead of 36. I’m not sure that the query string contains any tracking information that’s useful for the creator of this QR code – presumably this is just a result of copying and pasting the URL without pruning, with the result that the code will be harder to scan in less than ideal circumstances.

The path just contains company and a number, so we’re close to being able to encode this URL as alphanumeric (without lowercase letters) instead. However, typing COMPANY instead yields a 404 error, and in this case using alphanumeric encoding would still leave us with a version 4 code, with no improvement in density. Here is the resulting reduced code, at 29×29 and still with error correction level Q:

On to the second one:

  • Size: 37×37
  • Version: 5
  • Error correction: Q
  • Contents: HTTP URL with path (49 characters)

This URL leads to a Facebook page. Apparently, the URL is case insensitive, as going to the uppercased version redirects to the same page. An alphanumeric QR code encoding the uppercased URL is still a version 4 (33×33). However, we can get down to version 3 (29×29) by removing the www prefix of the URL. Again, this ultimately redirects to the same URL. At 45 characters and two sizes smaller, here it is:

And for the last one:

  • Size: 29×29
  • Version: 3
  • Error correction: Q
  • Contents: HTTP URL with path (29 characters)

Apparently this company managed to get a shorter Twitter handle than Facebook page name, as this QR code is fairly small already. The URL does not have a www prefix, which would have pushed it up to version 4 at this error correction level. Trying the uppercased URL does not give a redirect to the lowercased one, but still serves up the same page. Thus we can create an almost equivalent version 2 (25×25) QR code in all uppercase:

Pub menu

  • Size: 29×29
  • Version: 3
  • Error correction: M
  • Encoding mode: bytes
  • Contents: HTTP URL without path

As this URL does not contain a path, the entire contents is case-insensitive, and could thus be rendered in alphanumeric mode. With the same error correction mode, the above QR code would fit in 25×25 modules, version 2: