10 > 64, in QR Codes

This is really great, I didn&#x27;t know you could switch encoding schemes within the same QR code. There&#x27;s a nifty visualization tool [0] that shows how this can reduce QR code sizes. It can determine the optimal segmentation strategy for any string and display a color-code version with statistics. Very nice!<p>0: <a href="https:&#x2F;&#x2F;www.nayuki.io&#x2F;page&#x2F;optimal-text-segmentation-for-qr-codes" rel="nofollow">https:&#x2F;&#x2F;www.nayuki.io&#x2F;page&#x2F;optimal-text-segmentation-for-qr-...</a>

This is particularly useful for numeric data that is usually displayed in hex, like UUIDs [1]<p>I used this for digital QR code tickets [2], and it made the codes so much easier to scan, even with bad lighting.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39094251">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39094251</a><p>[2] <a href="https:&#x2F;&#x2F;workspace.google.com&#x2F;marketplace&#x2F;app&#x2F;qr_code_ticket_per_row_for_event_attenda&#x2F;9398047938" rel="nofollow">https:&#x2F;&#x2F;workspace.google.com&#x2F;marketplace&#x2F;app&#x2F;qr_code_ticket_...</a>

For dealing with larger data I would probably split the input bits into 63 bit chunks, which can be encoded in 19 decimal digits. 63 input bits turn into 19 digits which in turn is encoded in 63.33... output bits on average. This has an overhead of 0.53% instead of 0.34% of pure base10, which I think is acceptable. But then you don&#x27;t have to bring bignum libraries into the picture, as each chunk fits into a 64bit integral type.<p>64bit chunks are a little bit worse, with 4.16% overhead, so it might be worth dealing with the little complexity of 63 bit chunks.<p>I would also output the decimal digits in little-endian order.<p>edit: If you are willing to go for larger chunks then 93bit chunks would be my next candidate, there the overhead is 0.36%, barely more than pure base10&#x27;s 0.34%. I don&#x27;t think it&#x27;s worth going any higher.

I had an idea to embed a webpage in a dataurl and convert that to a QR code; the website would only exist on if you snapped the QR Code. I was dreaming of code-golf, demoscene, nft and weird business card applications, but the web-browsers ruined my fun because they won&#x27;t display dataURL unless you manually copy&#x2F;paste it into the URL bar.<p><a href="https:&#x2F;&#x2F;issues.chromium.org&#x2F;issues&#x2F;40502904" rel="nofollow">https:&#x2F;&#x2F;issues.chromium.org&#x2F;issues&#x2F;40502904</a>

I discovered the same thing when I was writing a tool the transmit data to a radio-free (no wifi or Bluetooth) airgapped computer and created a de-facto standard called &quot;qrint&quot;. The comment in this file has enough text for a blog post.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Chia-Network&#x2F;hsms&#x2F;blob&#x2F;main&#x2F;hsms&#x2F;util&#x2F;qrint_encoding.py">https:&#x2F;&#x2F;github.com&#x2F;Chia-Network&#x2F;hsms&#x2F;blob&#x2F;main&#x2F;hsms&#x2F;util&#x2F;qri...</a><p>Anyone who wants to use this, feel free.

We have a similar problem at work right now, but due to different constraints we&#x27;ve settled on Base85. Slightly denser than Base64, but still just plain old printable ASCII characters and the following characters are still &quot;free&quot; so one can use them as field delimiters in a CSV-style format:<p><pre><code> &quot;&#x27;,&#x2F;[]\ </code></pre> Incidentally, this also makes them JSON-Safe.<p>Base94 uses all printable characters, and Base122 uses both printable characters and whitespace.<p>UUIDs encoded in various alphabets:<p><pre><code> len algo value 24 Base64 padded wScmB8cVS&#x2F;K05Wk+nORR8Q== 22 Base64 unpadded osnQ3DUDTDuUQBc9mBRYFw 20 Base85 rHoLuTk%W0fgpY+`c&gt;xc 20 Base94 d(+H&quot;Q&#x2F;hP}i}d9&lt;KeAt)% 18 Base122 @#FoALt`92vSt@</code></pre>

<p><pre><code> qrencode -t UTF8 https:&#x2F;&#x2F;www.service.nsw.gov.au&#x2F;campaign&#x2F;service-nsw-mobile-app?data=eyJ0IjoiY292aWQxOV9idXNpbmVzcyIsImJpZCI6IjEyMTMyMSIsImJuYW1lIjoiVGVzdCBOU1cgR292ZXJubWVudCBRUiBjb2RlIiwiYmFkZHJlc3MiOiJCdXNpbmVzcyBhZGRyZXNzIGdvZXMgaGVyZSAifQ== </code></pre> vs<p><pre><code> qrencode -t UTF8 https:&#x2F;&#x2F;www.service.nsw.gov.au&#x2F;campaign&#x2F;service-nsw-mobile-app?data=072685680885510189821994892577900638215789419258463239488533499278955911240512279111633336286737089008384293066931974311305533337894591404330656702603998035920596585517131555967430155259257402711671699276432408209151397638174974409842883898456527289026013404155725275860173673194594939 </code></pre> The latter one is actually smaller. TIL

Cool article. What I&#x27;ve wondered, and the article doesn&#x27;t touch on: In &quot;normal&quot; usage (not damaged QR codes), what&#x27;s the best error correction to use, with a fixed output size (eg a sticker)? Using a higher level, results in more bytes, and thus a larger QR, which, when printed, results in smaller details. Is it better to have a low error correction, resulting in large blobs, or to have higher error correction, resulting in smaller details, which I guess will be harder to scan, but more room for correction?

<a href="https:&#x2F;&#x2F;zat.is" rel="nofollow">https:&#x2F;&#x2F;zat.is</a> uses uppercase base32 for URL checksums, as alphanumeric QR codes can contain 0–9, A–Z (upper-case only), space, $, %, *, +, -, ., &#x2F;, :. Overhead is only 10% (5.5 bits &#x2F; 5 bits). All links fit in a 33⨯33px image, margins included, so little point in improving on that for URLs so short. The tradeoff is that the checksum to URL mapping is stored in a backend and networking is required to learn anything about the real URL.

In an ideal world, the QR standard would include a specific URL encoding scheme that exactly matches the URL-safe character set. But I suppose there&#x27;s no real practical way to make big changes to the QR spec now, what with all the thousands of implementations in the wild.

This is fascinating, but I was curious about the last two QR codes. The left one is scannable on my iPhone (iOS 17.4.1) leading to <a href="http:&#x2F;&#x2F;example.com&#x2F;AAE..._w8fL" rel="nofollow">http:&#x2F;&#x2F;example.com&#x2F;AAE..._w8fL</a> whereas the one on the right gets only <a href="http:&#x2F;&#x2F;example.com" rel="nofollow">http:&#x2F;&#x2F;example.com</a> (both Safari and Firefox). Is this an iOS URL length limitation?

I need to re-run the math based on this info, but a while back, I wanted to figure out the maximum density of QR codes that could be reliably printed on a sheet of plain paper with a laser printer, then optically scanned and re-digitized. I recall the answer was about the same as a double-density 5.25&quot; floppy disk, which is 320kb.

I&#x27;m not sure if anyone uses Base36 any more (or its more obscure sister, Base32), but it uses [0-9, A-Z] as its alphabet. It is URL safe and also smaller than base 10 in character count for each number, and is the smallest standard URL-safe encoding that works with alphanumeric QR codes.<p>I sort of assumed this was common knowledge, but I guess not.

Why does the title have a &quot;&#x27;&quot; that isn&#x27;t in the document (&quot;&#x27;10 &gt; 64, in QR Codes&quot; versus &quot;10 &gt; 64, in QR Codes&quot;)?

1. Pretty neat to switch encoding in the middle of the URL. It does look like it works and it does look like a better encoding. This is cool.<p>2. I&#x27;d have called this base-1000. It&#x27;s using 3-digit numbers encoded into 10 bits. Base64 doesn&#x27;t encode into 64 bits, it uses 64 characters encoded into 6 bits. And this encoding uses 000 to 999, encoded into 10 bits. But that messes up the title when you compare apples to apples, 1000 &gt; 64 is just obvious and true.

I built an open source tool to specifically work on this problem: <a href="https:&#x2F;&#x2F;convert.zamicol.com" rel="nofollow">https:&#x2F;&#x2F;convert.zamicol.com</a><p>We know only two open source JS projects that even support alphanumeric, Nayuki and Paul’s. <a href="https:&#x2F;&#x2F;github.com&#x2F;Cyphrme&#x2F;QRGenJS">https:&#x2F;&#x2F;github.com&#x2F;Cyphrme&#x2F;QRGenJS</a>. We have it hosted here: <a href="https:&#x2F;&#x2F;cyphr.me&#x2F;qrgen" rel="nofollow">https:&#x2F;&#x2F;cyphr.me&#x2F;qrgen</a><p>I’ve also done a lot of work on this problem: <a href="https:&#x2F;&#x2F;image-ppubs.uspto.gov&#x2F;dirsearch-public&#x2F;print&#x2F;downloadPdf&#x2F;11580064" rel="nofollow">https:&#x2F;&#x2F;image-ppubs.uspto.gov&#x2F;dirsearch-public&#x2F;print&#x2F;downloa...</a><p>Also, regarding alphanumeric, RFC 3986 states that:<p>&gt; An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow “HTTP” as well as “http”)

Didn&#x27;t the EU covid passport decide to use the text encoding mode because it&#x27;s the only one that scanners supported reliably?

Thanks to the author&#x27;s previous post, I instantly recognised the `eyJ` prefix as the start of a JSON object!

base10 can be awkward to work with for large data, one can also consider:<p>base8 in numeric mode: 8 input bits -&gt; 3 digits -&gt; 10 output bits, 25% overhead<p>base32 in alphanumeric mode: 5 input bits -&gt; 1 character -&gt; 5.5 output bits, 10% overhead<p>I would prefer base32 out of these too, but it&#x27;s interesting that even base8 beats base64 here.

I&#x27;m not that familiar with QR codes. Anyone know how base16&#x2F;hexadecimal encoding with 0-9A-F fares in comparison? It seems like an obvious encoding to test, especially for simplicity of implementation compared to base64 and base10, and an odd one to miss for comparison?

We used essentially this technique in the SMART Health Cards specification for vaccine and lab result QRs.<p><a href="https:&#x2F;&#x2F;spec.smarthealth.cards&#x2F;#encoding-qrs" rel="nofollow">https:&#x2F;&#x2F;spec.smarthealth.cards&#x2F;#encoding-qrs</a><p>It&#x27;s well supported by scanners but can create unwieldy values for users to copy&#x2F;paste.<p>For more recent work with dynamic content (and the assumption that a web server is involved in the flow), we&#x27;re just limiting the payload size and using ordinary byte mode (<a href="https:&#x2F;&#x2F;docs.smarthealthit.org&#x2F;smart-health-links&#x2F;spec" rel="nofollow">https:&#x2F;&#x2F;docs.smarthealthit.org&#x2F;smart-health-links&#x2F;spec</a>)

you had me at hello

Or... Don&#x27;t encode data in the URL at all. If your data isn&#x27;t secret or per-user, have it go to <a href="https:&#x2F;&#x2F;yoursite.com&#x2F;gh" rel="nofollow">https:&#x2F;&#x2F;yoursite.com&#x2F;gh</a>. If it is security sensitive, go to <a href="https:&#x2F;&#x2F;yoursite.com&#x2F;Qhm4Qr55mS" rel="nofollow">https:&#x2F;&#x2F;yoursite.com&#x2F;Qhm4Qr55mS</a><p>2 alphanumerics (=4000 links) is plenty to encode a link to all the major pages of your website&#x2F;service you may want to advertise. 10 alphanumerics (=10^18) is plenty that even if every person in the world had a QR code, nobody could guess one before hitting your rate limiter.<p>The user experience gained by fast reliable scanning is far greater than that enabled by slightly improved offline support (offline functionality requires that the user already has your app installed, and in that case, you could preload any codes that user had access to).