It just encodes...codes?

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:

  https://example.com/01/09521207311511/21/1234ABDE1235

...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 3 hours ago | parent | next [-]

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.

	▲	3 hours ago \| parent \| next [-]
		[deleted]
	▲	ssl-3 3 hours ago \| parent \| prev [-]
		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.

▲ michaelt 3 hours ago | parent | prev | next [-]

> We can even add more real information and still have less data to encode

The reason they're so verbose comes from a few facts.

First of all, it's an existing logistics labelling standard, they've just replaced brackets with forward slashes and put a domain name on the front. So https://example.com/01/09521207311511/21/1234ABDE1235 is just a QR code version of those huge barcodes like (01)09521207311511(21)1234ABDE1235 you see on cases of products in the supermarket.

Second of all, the standard doesn't limit itself to a single date, so they can't identify dates with a simple ,D prefix. It's a kitchen sink standard [1] with 16 different types of date (production date, due date, packaging date, sell by date, best before date, expiration date, release date, first freeze date, harvest date, production date and time...) and just as many options for sizes and weights - so the identifier can be up to 4 digits. /11/ or /8008/

The third thing to know is QR codes pack different alphabets at different densities. Numbers at 3.5 bits per character, upper case letters and some symbols at 5.5 bits per character, ASCII at 8 bits per character. So the 13 characters of of "Apple Fuji Sm" uses about as much space in a QR code as a 29-digit number like "12345678901234567890123456789"

Fourth, you've replaced the 14-digit GTIN with an 11-digit UPC and replace the 13-digit serial number with a 5-digit lot code :)

IMHO the standard isn't going to take over the world, and anyone who says "Barcodes are about to go extinct" doesn't know what they're talking about. But it's not the information density, it's other reasons.

[1] https://ref.gs1.org/ai/

▲ kiallmacinnes 4 hours ago | parent | prev [-]

Absolutely - I 100% expect the links to lead to feel-good marketing fluff at best and end up being useless for consumers, but the stated goals are at least good.

It's just that, sadly, we can no longer have nice things.

	▲	ssl-3 3 hours ago \| parent \| next [-]
		And even spookier: Tracking. If items have unique (ie serialized) codes, then it's safe to assume that those codes will be recorded at purchase (since that's kind of the whole point), along with who bought them (yay discount cards and cashless society). Now the contents of my pantry describe things like where I've been, when I was there, and/or who I hang out with. Fun times! Even with cash and without discount cards: One random food label out of a recycling bin can relate all the way to photos of the purchaser's face at checkout, track them walking to their car, and see where that car went. This could happen months or years down the road. Most of those pieces are already in-place: Our photos are already recorded alongside of our transaction details -- that's been going on in POS world for a long time. Tracking people to their vehicle is a function of Avigilon camera systems. Tracking the car itself is the primary purpose of Flock. All that's missing right now is serialization records and a centralized database. I'm sure that nobody will ever finish fitting these things together into a cohesive system and that nobody would ever use it with ill intent. It probably would never happen anyway, since there's not a single retailer on Earth who would ever exchange this kind of data for an upgrade to their in-store surveillance systems and a monthly check. ;) (And we still don't get directly-useful consumer information into or out of these new 2D barcodes. I love losing.)
	▲	cxr 2 hours ago \| parent \| prev \| next [-]
		Instead, the URL should lead to the actual label in vector format, and most elements of the design should be clickable links.
	▲	petra 2 hours ago \| parent \| prev [-]
		It's possible to let the chat read the QR code and help the user with it.