It seems to be obscure that QR codes have an "alphanumeric" character set that includes everything you need to make URLs IF you use only uppercase characters. This increases the data density considerably.
(That is the digital twin of an installation on the wall behind me as I type, each square is 8 by 8 inches; the barcodes on the back of the cards are NOT high density, three-sided cards from that generation that link to external sites link directly to low density URLs. New generation three-sided cards use "QRLs" that redirect to external links.)
which are "version 2" QR codes that are larger only than "version 1" QR codes which don't have the little alignment dot in the lower right and don't scan as well. The URL above uses M level error correction, with L level error correction I can make URLs that are a bit longer.
I manage either length of code much like a type 4 UUID and in the later case the space is large enough that I (you and 8 billion of my closest friends) could make every URL unique and be perfectly able to track people at the expense of keeping a database entry for every unique code.
My take is that the degree of compression doesn't matter much in my case because with high density QR codes you can print them large enough that barcode readers have no problem with them.
My experience is that the QR code reading experience on iPhones is night-and-day better than that on cheap Android devices. I think a lot of people are testing barcodes on iOS and have no idea that they scan poorly or not at all for other uses. For one thing, any camera has a minimum depth that it focuses at and if you print a QR code too small you have to hold the camera close to the code to read it and the camera can't focus. Another problem is that most QR code reading programs just don't read white-on-black codes even if the standard allows them. For that matter, many QR code readers require much higher contrast than the standard specifies, and even the standard is conservative compared to what is possible with a generously sized code.
I make URLs that look like
https://gen5.info/$/XQ*42RXF-TLY:$B.8/
(That is the digital twin of an installation on the wall behind me as I type, each square is 8 by 8 inches; the barcodes on the back of the cards are NOT high density, three-sided cards from that generation that link to external sites link directly to low density URLs. New generation three-sided cards use "QRLs" that redirect to external links.)
which are "version 2" QR codes that are larger only than "version 1" QR codes which don't have the little alignment dot in the lower right and don't scan as well. The URL above uses M level error correction, with L level error correction I can make URLs that are a bit longer.
I manage either length of code much like a type 4 UUID and in the later case the space is large enough that I (you and 8 billion of my closest friends) could make every URL unique and be perfectly able to track people at the expense of keeping a database entry for every unique code.
My take is that the degree of compression doesn't matter much in my case because with high density QR codes you can print them large enough that barcode readers have no problem with them.
My experience is that the QR code reading experience on iPhones is night-and-day better than that on cheap Android devices. I think a lot of people are testing barcodes on iOS and have no idea that they scan poorly or not at all for other uses. For one thing, any camera has a minimum depth that it focuses at and if you print a QR code too small you have to hold the camera close to the code to read it and the camera can't focus. Another problem is that most QR code reading programs just don't read white-on-black codes even if the standard allows them. For that matter, many QR code readers require much higher contrast than the standard specifies, and even the standard is conservative compared to what is possible with a generously sized code.