The QR Code Is Not the Passport: How a DPP Data Carrier Works

Scan the code on a product built for the new EU rules and you might expect the passport to load. It doesn’t, at least not directly. What loads is whatever a piece of software in the middle decides to show you, based on who you are and what you asked for.

That piece of software in the middle rarely gets attention. The conversation about Digital Product Passports is usually about data: material composition, carbon figures, recycled content, repair instructions. All of it matters. But none of it reaches a phone by magic. Between the code on the product and the data on a server sits a small, unglamorous, and strategically important layer. Understanding it changes which questions you ask a vendor, and which decisions you cannot easily reverse once the labels are printed.

What is actually printed on the product?

An identifier, not the passport itself. The code carries a web address that uniquely names the product, and nothing more.

What goes under the QR code is usually a GS1 Digital Link URI, which conforms to the international standard ISO/IEC 18975:2024. The rules do not mandate it, other identifier schemes are allowed, but it is the approach almost everyone is converging on. In plain terms it is an ordinary web link with the product’s identity built into the path. A shopper’s camera reads it as a URL. A back-office system reads the same string as structured data.

If you already use GTINs, the global product numbers behind your barcodes, that same number becomes the identity at the core, followed by optional qualifiers that narrow it down. A serial number makes it one specific unit. A batch number makes it one production run.

https://id.example.com/01/09506000134352             product type
https://id.example.com/01/09506000134352/10/LOT456   a specific batch
https://id.example.com/01/09506000134352/21/SN12345  a specific unit

Those numeric keys (the 01, 10 and 21) are GS1 Application Identifiers, and they decide the passport’s granularity. Which level to use is the first real decision you make, because a delegated act tells you what your product needs. The table below uses GS1 identifiers as the example; other identifier schemes mark the same three levels their own way.

Item-level serialisation is mandatory for the batteries covered by Regulation (EU) 2023/1542: EV and LMT batteries, and industrial batteries over 2 kWh. Textiles usually sit at batch level, because dye lots and recycled content vary by production run. Get this wrong and you either print far more passports than you need, or too few to satisfy the rule. We covered where all this data actually comes from in what to do before 2027.

If the code is just a pointer, where does the passport live?

Somewhere else entirely, on a server, reached through a small piece in the middle called a resolver. The code points at the resolver, and the resolver points at the passport.

Think of an ordinary short link. Clicking one does not open a stored page; the link reaches a service that looks up where to send you and forwards you there. Change the destination in that service, and every existing link now points to the new place, even though the link itself never changed.

A resolver is that service, for a product code. The QR code holds a fixed web address. Scanning it does not open a file directly. It reaches the resolver, which looks up where that product’s passport currently lives and forwards the request there. None of this is exotic: a resolver runs on the same ordinary web standards the rest of the internet uses. GS1’s version, the GS1-Conformant Resolver Standard ratified in January 2026, is the most common way to do it, but it is one implementation of a vendor-neutral idea, not a requirement in itself.

Why put anything in the middle at all? Because the two ends move at different speeds. The code printed on the product is permanent. Once a million labels are out in the world, you are not recalling them to reprint. The data behind it is the opposite: it moves servers, changes format, gains fields, gets corrected. Point the code straight at one fixed file and the first change breaks it. The resolver is the joint that lets a permanent code sit in front of data that keeps changing. When the passport moves or changes, you update the resolver, not the product.

That is also how the code keeps working for years, which the rules require. The printed mark outlives whichever system happens to host the data, because the resolver sits between them and can always be repointed.

One thing the resolver is not: the EU DPP Registry. The registry is a central directory that authorities check to find and verify a passport. The resolver is the working layer that answers an everyday scan and serves the content. Different jobs: the registry is the index authorities look things up in, the resolver is what actually responds when someone scans.

A scan runs through the resolver to the passport. The EU DPP Registry is a separate directory that authorities check, not a step in the scan.

How does one QR code show different things to a shopper, a recycler and a regulator?

Through context. The resolver reads signals about who is asking and returns a different resource for each, all from the same printed code.

This is the feature that lets one code serve every audience a product has. When a request arrives, the resolver can look at the language the phone is set to, the type of content being requested, and the specific link asked for, then answer accordingly. GS1 defines named link types for exactly this: product information for a consumer, sustainability and end-of-life data for a recycler, traceability documents for a business partner.

Ask for everything at once and a conformant resolver returns a linkset, a machine-readable list of every resource attached to that identifier. That is how a recycler’s system, a customs platform, or a marketplace can discover what a product exposes without a human in the loop.

So the same square on the same box becomes a care guide for a shopper in Oslo, a disassembly instruction for a recycler in Rotterdam, and a compliance record for an inspector, with no second code and no reprint. The routing does the work.

QR, Data Matrix, RFID or NFC: which data carrier should you use?

Usually a QR code, but it depends on the product and the production line. As of 2026 the requirements for the carrier are set by a European standard, EN 18220.

Until recently, “use a QR code” was advice. Now it is specification. EN 18220:2026, published by CEN and CENELEC on 27 May 2026 and cited as a harmonised standard in the Official Journal on 15 July 2026, defines what a DPP data carrier has to do: symbology, encoding, durability and print quality. It is one of eight EN 18xxx standards from the committee CEN/CLC/JTC 24, six of which are already cited as harmonised standards. We follow that work directly through Standard Norge’s mirror committee, SN/K 624.

For most products a QR code is the right default: any phone reads it, and it prints cheaply. Under the ESPR, at least one data carrier has to be free to access and readable with an ordinary smartphone, no app to download, which is another reason a plain QR code is the safe default. Data Matrix earns its place on tiny items and fast lines. Textiles and tyres are where RAIN RFID starts to make sense, because you can read many item-level tags in a crate at once instead of scanning each by hand. NFC suits higher-value goods where a tap feels natural, though it is still maturing for DPP use.

A logo dropped into the middle of a QR code is, to the scanner, damage. QR codes build in error correction to tolerate some wear, but a logo spends that margin up front. The rules reward a code that still scans after a year on a pallet, not one that looked good in the brand deck.

There is a clock on this too. Retail is moving its checkout scanners to read 2D codes under the industry’s Sunrise 2027 effort, and until enough tills can read them, many products carry both the old linear barcode and the new 2D code. That transition is a reason to settle your carrier now rather than reprint twice.

Who controls the resolver, and why does it matter for you?

Whoever runs your resolver decides where every scan of your product goes, for the life of that product. Holding that yourself or handing it to your provider is a real choice, and neither answer is wrong.

The resolver is also a business asset, not just plumbing. It is the channel to everyone who ever picks up your product: the customer registering a warranty, the repairer looking up a part, the buyer checking your compliance. Whoever operates it decides what those people see, and can change it.

The catch is the permanence of the printed code. Whatever domain it carries, it carries for the life of the product. So the one decision worth making with your eyes open is whose domain that is, because it sets how easily you could ever move. There are two honest ways to do it, and the difference is a trade-off, not a trick.

Your own domain. Your codes carry a domain you own, say id.yourbrand.com, pointed at your provider’s resolver with a single DNS setting called a CNAME. You get maximum portability: to change provider later, you repoint that one setting and every printed code keeps working. The cost is a little setup, someone who can add a DNS record, usually an IT contact or whoever manages your domain.

Your provider’s domain. You let your provider run everything on its domain, with nothing for you to own, set up or maintain. For plenty of manufacturers that is the point: one less system to manage, no DNS or IT dependency, and a single provider accountable for keeping the passport reachable. The trade-off is that the printed codes carry the provider’s domain, so a later move is harder. If you are happy with your provider, that can be a fair price for the simplicity.

At DPPA we support both, and neither is the wrong answer. For customers who want to own it, we have a way to run your codes on a domain you keep, so you could move later without reprinting. For those who would rather we simply handle all of it on ours, that is completely fine, and often the simpler path. What matters to us is that the choice is yours and you make it knowingly, the same way becoming a verified operator keeps the responsibility clearly with you.

Not sure which of the two fits you? It is one of the first things we map with a customer. Book a demo and we will walk through it for your products.

What should you get right before you print a single code?

Get three things right before you print: the granularity, the identifiers, and the domain your codes point to. Everything else you can change later.

Three decisions outlast everything else, because they are set into the physical product the moment it ships.

First, the granularity. Confirm whether your product group needs model, batch or item level, and design your serial scheme once, with room to grow. Second, the identifiers. Own the numbers that identify your products, so your product identity is not borrowed from a platform you might one day leave. If you use GS1, that means your own company prefix and your own GTINs, rather than numbers lent to you by a provider. Third, the destination. Decide whose domain your printed codes carry, your own for maximum portability or your provider’s for zero setup, and go in knowing the trade-off rather than discovering it later.

Everything downstream of those, the passport content, the integrations with your existing systems, the exact fields a delegated act asks for, can be added and corrected over time. The code on the box is the one part you print once and live with. Treat the first scan as the deadline for the decisions that are hard to undo, not for the data that is easy to update.

FAQ

The code you print is the one decision you cannot easily take back, so it is worth getting the layer beneath it right before the labels go out. DPPA builds Digital Product Passport infrastructure with a focus on item-level identifiers you own and a resolver on a domain you keep, so you can change how a passport works without touching the product. We build against the GS1 and EN 18220 standards, and we sit on Standard Norge’s DPP committee, SN/K 624, the Norwegian mirror of CEN/CLC/JTC 24. If you want a straight answer on how your product codes should work, book a demo.

For what happens after a scan reaches the authorities, see The EU DPP Registry: What It Actually Stores, and What It Doesn’t.