I was on a call yesterday with a leader in the fashion supply chain and manufacturing industry. Someone with significant experience working with brands shipping to the EU. We were talking about Digital Product Passport requirements for 2027.
A few minutes in, he asked a question that I think almost anyone reading about DPP for the first time would ask:
“So basically DPP is just a QR code on the garment, right?”
It is a fair question. Every DPP article opens with a photo of someone scanning a QR code on a shirt tag. Every vendor demo ends on a glossy landing page popping up on a phone screen. If that is all the visible surface of a DPP, the conclusion writes itself.
The QR code part is genuinely easy. Any GS1-compliant barcode generator can produce one in a few seconds. The harder parts of a DPP sit behind the scan. Data collection from your suppliers. Event capture across your supply chain. And a component most people have never heard of called a GS1 Digital Link Resolver.
This post is about that last piece. Not because it is the biggest part of the work. The supplier data layer and the traceability engine both demand real effort too. But the resolver is the piece that quietly decides whether your DPP actually works when someone scans it. Or whether it just shows a pretty page that fails a regulator’s request.
One QR Code, Four Audiences
Start from the scan itself. A Digital Product Passport has one QR code on the product. But it does not have one reader.
A consumer scans it and wants care instructions, origin, and sustainability claims in their own language.
A customs officer scans it at a port and wants structured compliance data. Material composition. Country of origin per component. Certifications with issuer and date.
A retailer auditor scans it and wants the full traceability trail. Which supplier. Which batch. Which shipment event at which facility.
A recycler scans it at end of life and wants disassembly instructions and material recovery data. Nothing else matters to them.
Same product. Same QR. Four different answers, each of them correct for the person asking.
That is not a QR code problem. That is a resolver problem.
What a GS1 Digital Link URL Actually Is
Before we get to the resolver, the URL itself deserves one minute of attention. Most people look at a QR code and assume the URL inside it is a normal web link. It is not.
A GS1 Digital Link URL looks like this:
https://id.brand.com/01/09506000134352/10/AB-123/21/00001
Each segment means something specific. The 01 is the application identifier for GTIN. The number after it is the product’s GTIN. The 10 flags a batch number. The 21 flags a serial number. This is GS1 syntax, encoded inside a standard HTTPS URL.
That dual nature is the whole point. The same string is a GS1 identifier that any GS1-compliant system can parse. And it is a web address that any phone camera can open. One URL, two identities.
This matters because the URL carries the identity of the product. The content on the other end is not hard-coded. It is decided, per scan, by the resolver.
What a Resolver Does
A resolver is not a URL shortener. It is not a webpage. It is a standards-aware routing service. When a scan hits the resolver, it does four things in order.
Parse. Pull the URL apart. Identify the GTIN, the batch, the serial, any other GS1 application identifiers present.
Match. Figure out which link type the caller is asking for. GS1 defines a vocabulary for this. gs1:pip for the brand or retailer product information page. gs1:certificationInfo for certification information. gs1:traceability for track and trace information. gs1:epcis for EPCIS visibility event data. gs1:productSustainabilityInfo for sustainability, recycling, and manufacturing information. gs1:recallStatus for product recall information. The full list is published in the GS1 Web Vocabulary. A DPP-specific link type is in active discussion but is not yet part of the published vocabulary, so most current implementations reuse the existing types above.
Negotiate. Decide the right response based on context. Who is asking. Which locale. Which format (HTML for a phone, JSON-LD for a regulator’s system). The GS1 Digital Link standard specifies how this negotiation works, mostly through the Accept header and an optional linkType query parameter.
Route. Send the request to the right downstream destination. Could be a static localized page. Could be a DPP viewer. Could be an EPCIS repository query. Could be a brand’s product API. Could be a regulatory endpoint.
The QR code does not encode the content. It encodes the identity. The resolver decides what content to serve for that identity, in that context, at that moment.
Why “Just Point to a Webpage” Breaks
Think back to the conversation at the start. If the plan is “generate a QR code, point it to a product page on our website,” here is what happens the day a buyer, a customs officer, and a recycler each scan it.
The buyer sees the marketing page. Fine for them.
The customs officer gets the same marketing page. Their compliance system cannot parse it. They ask the exporter for the structured data separately. The DPP did not serve its purpose.
The recycler, years later, scans the QR and gets the same marketing page. If the brand has since taken the page down, the scan returns a 404. The DPP is dead.
Four failure modes, all avoidable:
- No content negotiation. A single static page cannot answer different audiences. The resolver is what makes one URL answer many questions.
- No standard vocabulary. Custom schemas fracture interoperability. Two brands doing their own thing means any app that scans across brands breaks.
- No decoupling. If the content destination changes, you cannot re-print the QR codes that are already on products in the field. A resolver lets you change destinations without changing the printed identifier.
- No registry alignment. National resolver services exist. GS1 US operates Verified by GS1. GS1 India has its own resolver. These speak the standard. A custom landing page cannot integrate with them.
These are not edge cases. These are design requirements baked into how a DPP is expected to behave across a product’s lifetime.
What This Looks Like for a Textile DPP
Make it concrete. A textile product under ESPR in 2027 carries a DPP. Here is how a compliant resolver responds to four different scans of the same QR code.
A consumer opens their phone camera. The resolver sees an Accept: text/html header from a mobile browser with an Indian English locale. It routes to a localized DPP viewer page. Short, readable, visual. Composition, care, origin, a sustainability score.
A customs officer’s system sends Accept: application/ld+json with linkType=gs1:certificationInfo. The resolver returns a JSON-LD document with structured certification claims and their issuer GLNs. Until the GS1 Web Vocabulary adds a dedicated DPP link type, a regulator-facing response typically composes existing types like gs1:certificationInfo and gs1:traceability into a single DPP document.
A retailer’s auditor sends linkType=gs1:traceability. The resolver queries the EPCIS repository and returns the event history for that batch. Every ObjectEvent, every TransformationEvent, every handoff.
A recycler’s app in 2032 sends linkType=gs1:productSustainabilityInfo. The resolver returns disassembly instructions and a material recovery profile.
One QR. One URL. Four responses. Each one complete, each one correct.
Where the Resolver Sits in the Architecture
If you sketch a DPP system on a whiteboard, the resolver sits in the middle of the data flow. Not at the edge.
Upstream of the resolver: your master data (GTINs, GLNs), your EPCIS repository (events from your suppliers and your operations), your content sources (DPP documents, certificates, localized pages), and any regulator APIs you have to expose.
Downstream: every possible scanner. Consumer phones. Customs systems. Retailer audit tools. Recycler apps. Brand protection apps. National resolver services.
The resolver is the layer that makes all those downstream readers work off the same upstream truth. Remove it and every reader needs a custom integration. Add it and the system scales to readers that did not exist when the product was manufactured.
What We See from the Build Side
A few lessons from real builds:
Design for link type negotiation from day one. Retrofitting it later means re-architecting routing logic. Build it in at the first line of resolver code.
Keep the resolver stateless. It should hold no content itself. Only routing logic. The content lives in downstream services. This keeps the resolver small and fast.
Plan for unknown future link types. The DPP vocabulary will grow. Your resolver should treat link types as data, not code. New types should be a config change, not a deployment.
Do not skip the registry alignment. If you are serving Indian or European markets, your resolver needs to eventually speak to the national resolver. Design the handoff early.
One Diagnostic for Your DPP Plan
Here is the test worth running this week against any DPP proposal you are evaluating. Whether you are buying, building, or inheriting.
Pick one product. Imagine the same QR scanned by four different readers: a consumer phone, a customs system, an auditor’s app, a recycler’s app.
Ask: does the DPP design return a different, correct response to each one? Or does it return the same landing page to all of them?
If it is the same landing page, you have a QR code pointing at a webpage. Not a DPP.
The difference is the resolver. It is not the biggest part of the work. But it is the part that decides whether a DPP behaves like a DPP or like a marketing link.
I am curious about one thing specifically. For teams that are already designing their DPP architecture: where are you putting the resolver? Inside your product catalog system, inside your EPCIS repository, as a standalone service, or are you planning to use a national resolver like GS1 US or GS1 India? The right answer likely depends on scale and regulatory market. But the options are not equivalent, and the decision is harder to change later than to make now.
If you want the data model context behind this, see the companion post on the GS1 DPP Provisional Standard.
