As I understand it, The key bits of data are in the QR code, they are just encoded as a URL - a highly structured URL that point of sale systems can decode without visiting the URL.
Doing it this way means the QR code is directly usable by consumers to get to a product info / marketing page, and directly usable by the POS systems.
We have the technology to encode a short, plain human-readable description of an item into a 2D barcode, with born-on and/or sell-by dates, and/or things like serialization and/or lot codes, or other useful things.
Brevity is important; fields can have a standardized-but-flexible format that fits the particular item's needs.
A single-quantity small Fuji apple, picked today (October 3, 2026), with a PLU of 4129, and a magic-number lot code of b29sF, distributed by Stemilt Growers might present as such:
Apple Fuji Sm,B0261003,P4129,Lb29sF,MStemilt
A single 1.5 liter bottle of Crystal Geyser spring water with a UPC of 07514000500, a best-by date of January 12 of 2028, and a lot code of kek67:
Water Spring 1.5l,D0280112,U07514000500,Lkek67,MCG
We can even add more real information and still have less data to encode than:
...but, I mean: A coded URL for a website that might be designed to avoid being forthcoming with information isn't necessarily any better for consumers, long-term, than the UPC we've had for over 50 years. It's still just a pointer that relates to someone else's database. It has no informational value on its own.
The advantage of using a hyperlink is that consumers do not need an application-specific decoder, they can use their standard reader. And manufacturers can provide additional data (in theory: user manuals, but in practice most likely 404s, tracking and ads).
As I understand it, fields are standardized. I don't think they contain the name of the product (I didn't read the spec), but the other info is there, so no need to hit the servers/db on other servers.
As for the quantity of data, Qr codes have special encoding modes depending on the content. The numeric mode uses 3.3 bits per digit, the alphanumeric 5.5 bits per character (45 characters in the set). Switching modes in the stream is supported, though it adds a few bits of overhead.
Looking at the examples, it looks like the scheme is not as efficient as it could be (pesky slashes, alphanumeric at the end), but that's not too bad either.
There's ways to shrink the bit cost down, for sure. The commas in my example are particularly expensive, for instance, since commas aren't part of QR's alphanumeric set.
It was just a quick expression of an idea, presented in the form of a gripe; it's not a formal specification.
As to consumers, and their hardware: People still get new phones and features can be (and sometimes actually are) added to existing phones. I'm not too worried about it as a constraint; things would catch up soon enough.
byte-sized-snac · · focus · HN ↗
Surely the actual data will be stored in the QR code and available offline
kiallmacinnes · · focus · HN ↗
Doing it this way means the QR code is directly usable by consumers to get to a product info / marketing page, and directly usable by the POS systems.
Edit: I looked it up. An example URL:
<a href="https://example.com/01/09521207311511/21/1234ABDE1235" rel="nofollow">https://example.com/01/09521207311511/21/1234ABDE1235
01 is a marker before the traditional barcode.
21 is a marker before the serial number.
There seems to be many other codes like 17 (expiry date) and 10 (batch number).
ssl-3 · · focus · HN ↗
We have the technology to encode a short, plain human-readable description of an item into a 2D barcode, with born-on and/or sell-by dates, and/or things like serialization and/or lot codes, or other useful things.
Brevity is important; fields can have a standardized-but-flexible format that fits the particular item's needs.
A single-quantity small Fuji apple, picked today (October 3, 2026), with a PLU of 4129, and a magic-number lot code of b29sF, distributed by Stemilt Growers might present as such:
A single 1.5 liter bottle of Crystal Geyser spring water with a UPC of 07514000500, a best-by date of January 12 of 2028, and a lot code of kek67: We can even add more real information and still have less data to encode than: ...but, I mean: A coded URL for a website that might be designed to avoid being forthcoming with information isn't necessarily any better for consumers, long-term, than the UPC we've had for over 50 years. It's still just a pointer that relates to someone else's database. It has no informational value on its own.MayeulC · · focus · HN ↗
As I understand it, fields are standardized. I don't think they contain the name of the product (I didn't read the spec), but the other info is there, so no need to hit the servers/db on other servers.
As for the quantity of data, Qr codes have special encoding modes depending on the content. The numeric mode uses 3.3 bits per digit, the alphanumeric 5.5 bits per character (45 characters in the set). Switching modes in the stream is supported, though it adds a few bits of overhead.
Looking at the examples, it looks like the scheme is not as efficient as it could be (pesky slashes, alphanumeric at the end), but that's not too bad either.
ssl-3 · · focus · HN ↗
It was just a quick expression of an idea, presented in the form of a gripe; it's not a formal specification.
As to consumers, and their hardware: People still get new phones and features can be (and sometimes actually are) added to existing phones. I'm not too worried about it as a constraint; things would catch up soon enough.