In an upcoming app I'm using QR codes containing app associated links to bootstrap connections from one device to another. iOS and most Android devices ship with QR code support in their built-in camera apps, so if the app isn't installed users can be directed to an app store, and if it is they'll launch straight into the app.
QR codes are made up of one or more segments, each of which can be be in one of
four standard encodings that cater to specific datatypes. For URLs the two encodings
of interest are binary, which can contain any byte sequence, and alphanumeric, which can contain 0
to 9, A to Z, space, $, %, *, +, -, ., / or :. With maximum error correction a QR
code can contain a maximum of 1,273 bytes or 1,852 alphanumeric characters.
URLs have a practical limit of around 2,000 bytes so very long URLs may not fit in a QR code encoded with maximum error correction. Fortunately the URLs the app uses will be well under 500 bytes so even if the URLs aren't appropriate for the alphanumeric encoding they'll fit without issue. Still the more efficient alphanumeric encoding may be of benefit if it can produce smaller images.
| URL | Length | Image | Size |
|---|---|---|---|
| https://example.com/ | 20 | 29 | |
| HTTPS://EXAMPLE.COM/ | 20 | 25 |
That proves true in the example above.
| URL | Length | Image | Size |
|---|---|---|---|
| https://www.example.com/ | 24 | 29 | |
| HTTPS://WWW.EXAMPLE.COM/ | 24 | 29 |
Change the URL slightly though and its a dead heat. So it'll depend on the actual content as to how much benefit there is, if any, in making the URL alphanumeric friendly.
For this app I want to place a binary payload of 33 to 137 bytes in the fragment of a URL with the
payload type identified by a single character path. The fragment character (#) is not in the
alphanumeric range, so there will need to be at least one binary segment. The payload itself could
be encoded in unpadded Base32 Hex to make it both URL and alphanumeric friendly, or as
unpadded URL safe Base64 which will produce a smaller URL but a potentially larger QR code.
| URL | Length | Image | Size |
|---|---|---|---|
| HTTPS://LOCALDEVICELINK.COM/A#V30GKKSSSKN7FG09AADU8BBMNS4536N35HQRS1QGJ7H2MT5T0P7PG | 83 | 45 | |
| HTTPS://LOCALDEVICELINK.COM/A#-MEKU5zlLnfACVKb5C12vwhRmuMsdb4HUJniK3S9Bk-Y | 74 | 49 | |
| HTTPS://LOCALDEVICELINK.COM/A#V30GKKSSSKN7FG09AADU8BBMNS4536N35HQRS1QGJ7H2MT5T0P7PHO9AEEU0AJKNS0KN5EO49MBDUA3HN81KP5EU4TOBI0IBIJEICRTO05597N15DQRG0ICIRCI6RDNV928TK8RCMNV4F46P49LR9VA6HVC22QLJVH2OTLP0D6PFMH4DQOFMHCFQ8E6DA7J7M3SK52UK3LJAVU21HB9HOPDEUT00 | 250 | 69 | |
| HTTPS://LOCALDEVICELINK.COM/A#-MEKU5zlLnfACVKb5C12vwhRmuMsdb4HUJniK3S9Bk-Y4SpzvAVOl-ApcrsETZbfKHG6A0yV3idwuQJLlN0mb7gBSpPcJW63AEmS2yRttv9IkdojbLX-R5DZImu0_UaP2CFqs_xFjtcgabL7RI3WH2ix-kOM1R5nsPlCi9QdZq_4QYrTHGWu90A | 213 | 77 |
While the difference isn't huge, using Base32 Hex to produce larger but more efficiently encodable URLs may be enough to squeeze an image into a space it otherwise might not have fit. As the URLs do not need to be human friendly and the QR codes may be displayed on small screens this trade off is worth it for this application.