The DPP QR Code: Why It Has to Be a GS1 Digital Link, Not a Link to Your Product Page

Every Digital Product Passport conversation eventually arrives at a square black and white box. The code on the product is the only part of the passport a customer, a repairer or an inspector ever physically touches, and it is the part most often built as an afterthought: generate a QR, point it at the product page, ship it.

That works for about eighteen months. Then the URL changes, or the platform changes, or the product is discontinued and the page is deleted, and every unit already in the field carries a code that resolves to a 404 or, worse, to a redirect chain that lands somewhere plausible and wrong.

This piece is about the carrier: what the law asks of it, what GS1 Digital Link is, how the URI is actually put together, and the two mistakes that are easy to make and expensive to unwind.

What the law asks of the carrier

Two instruments speak to this, and they say different amounts.

The ESPR framework, Regulation (EU) 2024/1781, handles it at Articles 11 and 12. Article 12 is about unique identifiers and Article 11 about technical design and operation. The requirement that matters commercially is that the identifier behind the passport is persistent and free of vendor lock in. A passport reached through an identifier your software vendor minted and owns is a passport you lose when you change vendor, which defeats the point of attaching data to a product that will outlive several of your systems.

The Batteries Regulation, Regulation (EU) 2023/1542, is far more specific because its passport is adopted law. Article 77(6) requires that the code on the battery resolve to a unique, permanent address serving that battery's passport. Read that as three separate demands. Unique: this code answers about this thing, not about a family of things. Permanent: it survives your replatform, your domain reshuffle and your catalogue cleanup. Serving that battery's passport: a marketing page with a sustainability section on it is not a passport, and nobody is going to accept it as one.

Worth stating plainly: the Batteries Regulation applies from 18 February 2027, and only to LMT batteries, electric vehicle batteries and rechargeable industrial batteries above 2 kWh. If you are outside that scope, none of this is a legal obligation for you today. It is still the design you want, because the alternative is reprinting labels.

What GS1 Digital Link is

GS1 Digital Link is a convention for putting a GS1 identifier inside an ordinary web URL, so that one code can be both a machine readable identifier and a link a phone camera can open.

The GTIN, the Global Trade Item Number, is the number under the barcode you already put on products. Digital Link expresses it as a path segment with an application identifier in front of it. The application identifier for a GTIN is 01, so the URL looks like this:

https://passport.example.com/01/09506000134352

That is the whole trick, and its usefulness comes from what it is not. It is not an opaque token. Anything that understands the convention can read the GTIN straight out of the path without asking you what your URL scheme means. It is not a redirect to a page you happen to have today: the address is the identifier, so the identity survives whatever you do with your storefront.

Two properties fall out of that, and both are the reason to prefer it over a homegrown scheme.

The identifier is yours, not your vendor's. Your GTIN is issued to you. Move platforms and it moves with you. Contrast that with a passport addressed by a vendor's internal record id, which is a hostage.

Machines can act on it without integration work. A resolver can answer a discovery call and hand back the set of links it knows about for that product. The GS1 web vocabulary has terms for this, and a passport typically answers under the sustainability information link type alongside the ordinary product information page. Inventing your own vocabulary term here defeats the reason for using a standard identifier at all, because no other resolver will understand your answer.

One important status note, and we label it this way everywhere in the product: GS1 Digital Link is the carrier form the Commission's preparatory work points at. It is a strong candidate, not a legal designation. The horizontal standards work under CEN and CENELEC on identifiers, data carriers, access rights and interoperability was still in progress at our last reading on 20 August 2026. Anyone telling you the law requires GS1 Digital Link today is overstating it. Anyone telling you to therefore invent your own scheme is giving worse advice, because a candidate standard with the whole preparatory apparatus behind it is a much better bet than a URL pattern you made up on a Tuesday.

Qualifiers: model, batch, unit

The GTIN identifies a product model. A passport often needs to be about something narrower, and this is where the URI grows.

Digital Link adds qualifiers as further path segments, each with its own application identifier. Two matter here:

• /10/ is the batch or lot number. So https://passport.example.com/01/09506000134352/10/A2261 asks about the units made in that production run.
• /21/ is the serial number. So https://passport.example.com/01/09506000134352/21/7X1104 asks about exactly one physical unit.

The rule that governs both is one sentence long and it is the single most important implementation detail on this page.

Qualifiers narrow. They never widen.

If a code carries a serial and your resolver has no passport for that serial, the correct answer is "no passport for that unit". The tempting answer, falling back to the model level passport, is wrong, because it answers a question nobody asked. Somebody scanned a specific unit. Handing them the model record looks like a successful scan and quietly substitutes generic data for unit data.

On a battery that substitution is not cosmetic. State of health is per unit and it decays. A second life operator scanning a used pack and receiving the model's nominal figures instead of that pack's measured ones is being handed a number that looks like a measurement and is not. Refusing to answer is the honest outcome, and it is the one to build.

The GTIN normalisation trap

Here is the bug that will bite you in testing, and it looks like a data problem when it is a code problem.

GTIN-8, GTIN-12, GTIN-13 and GTIN-14 are not four different numbering systems. They are the same number, right aligned in a fourteen digit field. A GTIN-14 is a GTIN-13 with a leading zero in front of it. Your PIM stores the EAN-13, your label printer emits the GTIN-14 for the case, and both denote the same product.

A resolver that compares strings returns a 404 for a perfectly good label. The fix is to normalise every incoming GTIN to its fourteen digit form and look up on that, and to accept every equivalent stored form of the same number. You do not need to recompute check digits to do it: the check digit is the last character and is identical across all four forms, so a GTIN-14 with its left padding stripped is the shorter form that was padded.

This is worth testing deliberately with a real printed label rather than with the value you typed into a form, because the two often differ in exactly this way.

What a scan should actually return

A passport URL is scanned by two very different clients, and serving both the same thing makes one of them wrong.

A phone camera opens the link in a browser and sends an HTML preference. That client wants a rendered page, in a human language, showing the fields the scanner is entitled to see. A machine agent, a recycler's intake system or an inspection tool, usually wants structured data and often states no preference at all. Redirecting it to HTML just means it gets scraped, badly.

So the sensible behaviour is content negotiation: an explicit HTML preference gets the page, an explicit JSON or JSON-LD preference gets the payload, and no stated preference gets the payload. A discovery call asking for all link types gets the link set rather than any single document.

None of that is exotic. It is the difference between a passport that other people's systems can consume and one that only works when a human is holding a phone.

Where the passport should live

Three practical decisions, in the order they bite.

Put the resolver on a domain you control and intend to keep. Not a vendor subdomain, not a shortener, not a campaign domain. The address has to outlive the product, and for a battery the product might be in service for a decade after you stop selling it.

Never print a code you cannot re-resolve. Once a label is printed, the URL in it is frozen. Everything downstream of the resolver can change; the resolver address cannot. This is the reason to separate the two in the first place, and it is why pointing a printed code at a product page is such an expensive shortcut: it fuses an address that must never change to a page that will.

Decide the granularity before you print, not after. Model, batch or unit is a decision about what the code will be able to answer forever. Adding a serial later means new labels for everything already made.

How this fits the rest of the passport

The carrier is only the door. Behind it sits the dataset you are able to serve, which depends on which product group you are in and whether a delegated act exists for it, and the access rules that decide which fields each scanner is entitled to see. Those two are covered in the plain explainer on what a Digital Product Passport is and in the piece on access tiers.

Our own Digital Product Passport tooling resolves passports over a GS1 Digital Link built on your GTIN rather than on an identifier we minted, normalises GTIN forms so a padded label and a stored EAN find the same product, and treats a lot or serial qualifier as narrowing only. Where we hold no passport for the specific unit that was scanned, it says so instead of substituting the model.

What it does not do is tell you that any of this makes you compliant. It reports how much of a named, cited dataset you hold, and names the regulation and article behind every field so your own counsel can check the reading. None of this is legal advice.