Digital Product Passport QR Code: Access, GS1 Digital Link and Resolvers Explained

This page explores one part of the Digital Product Passport. For implementation, the DPP data model connects product identity, fields, evidence and access rights.

How do you open a Digital Product Passport?

In the normal journey, a person scans the carrier on the product, packaging or accompanying documentation. The carrier contains a unique product identifier (UPI) or a web address built from it. That identifier leads to the appropriate view of the Digital Product Passport (DPP). Public data may open immediately, while protected fields are delivered only after a role or permission check.

The ESPR does not impose one universal QR code on every product. It requires a connection between a standards-compliant data carrier and a persistent unique product identifier. The relevant legal act determines which product group is covered, where the carrier is placed and whether identification occurs at model, batch or item level. See the overview of DPP product groups and timelines for those distinctions.

Why the DPP QR code is not the product passport

A QR code is a two-dimensional data carrier. It can encode a web address that a smartphone camera opens. The DPP is the underlying product dataset: identity, required attributes, evidence, access rules, versions and machine-readable outputs. Linking only to a marketing landing page does not provide those properties.

This separation makes access maintainable over time. Product information can be updated or migrated to a new system without replacing every printed label, provided the company retains control of the identifier, domain and resolution layer.

What role does GS1 Digital Link play in a Digital Product Passport?

GS1 Digital Link defines how GS1 identifiers are expressed inside a web address. An existing GTIN can therefore identify an item at checkout and also lead to the product’s digital information space. The GS1 Digital Link standard separates stable product identity from changing digital destinations.

That is attractive for many consumer products: the same GS1-based identity can support retail, logistics, consumer information and a DPP. A resolver can offer different resources according to requested link type, language, format or permission. GS1’s quick-start guide explains those two functions—identification and linking—through practical URI patterns.

What can a GS1 Digital Link for a DPP look like?

The following example uses GS1 Application Identifier 01 for the GTIN and 21 for a serial number. The domain, identifier and targets are fictional. The URI is the identifying entry point; a resolver can then deliver the appropriate DPP resource.

{
  "gtin": "09506000134352",
  "serialNumber": "SN-4711",
  "gs1DigitalLink": "https://id.example.com/01/09506000134352/21/SN-4711",
  "availableResources": [
    {
      "linkType": "digital-product-passport",
      "mediaType": "text/html",
      "target": "https://dpp.example.com/products/SN-4711"
    },
    {
      "linkType": "digital-product-passport",
      "mediaType": "application/json",
      "target": "https://api.example.com/dpp/SN-4711"
    }
  ]
}

A model- or batch-level passport would qualify the identity differently. A serial number should therefore not be inserted into every code by default. First determine the legally required granularity, then design the identifier scheme, resolver rules and carrier.

For a broader data model covering identity, evidence and JSON, see the DPP example and template.

GTIN, batch or serial number: which identifier does the passport need?

A GTIN typically identifies a trade item or model. It does not automatically distinguish every manufactured unit. If a DPP applies to a specific batch or item, the identifier needs an appropriate qualifier—such as batch or serial number—or another suitable identification scheme.

The choice affects data volume, printing and production processes, event data, traceability and cost. It should therefore be evaluated alongside the product group’s DPP requirements, rather than as an isolated barcode project.

Does the data carrier have to be a QR code?

No. The ESPR defines the carrier as the machine-readable connection between product and identifier, while leaving the concrete technology to product-specific measures. The harmonised standards published in July 2026 cover unique identifiers, data carriers, exchange protocols, storage, APIs and system interoperability. EU Decision 2026/1736 lists the six DPP standards.

In practice, a web-capable 2D code is compelling when consumers should access the passport without a specialist app. Industrial or protected journeys may justify multiple carriers or additional authentication. The essential requirement is consistent mapping to the same product identity.

Why a resolver can be better than a hard-coded destination

A simple QR code can point directly to one DPP page. That works, but it tightly couples the printed mark to that storage location. A resolver keeps the product identity stable and manages the available destinations. The human view, API, instructions, repair information and recycling data can then evolve independently.

• Use an HTTPS domain the organisation controls for the long term.
• Separate identity from the target system so providers can be changed.
• Describe languages, media formats and link types unambiguously.
• Maintain redirects, error handling and discontinued products over time.
• Do not use a short-lived campaign URL or third-party URL shortener as the persistent identity.
• Plan monitoring, backup and recovery for the resolution service.

These requirements belong in the DPP implementation roadmap and in the evaluation of DPP software or a service provider.

Do consumers, authorities and repairers see the same DPP?

Not necessarily. The unique identifier can remain the same while delivered fields depend on access rights. Consumers may need care, material, repair or disposal information. Market surveillance and customs may require additional compliance or registration data. Repair and recycling organisations may receive technical information that is not intended for the general public.

The ESPR does not make those rights identical for every product. Product-specific measures define which actors may access which fields. A technical implementation should therefore separate public and protected resources without creating contradictory product identities.

How is a DPP opened online or without the physical code?

The ESPR recognises that potential customers cannot scan a product in an online offer. The responsible economic operator must provide dealers and online marketplaces with a digital copy of the carrier or the unique product identifier so access can be exposed in the listing. A digital copy or web link must also be provided promptly and free of charge on request.

For the user journey, a normal text link is often better than only an image of the QR code. It is more accessible, works on the same device and can be processed by search, assistive and procurement systems. The QR code and clickable link should therefore resolve through the same controlled product identity.

The ESPR guide explains how the framework regulation and product-specific measures combine to create these obligations.

Does the DPP come from the EU Registry?

No. The EU DPP Registry mainly stores identifiers, registration data, metadata and the reference to the externally hosted passport. The 51-page EU guide explicitly says that the complete DPP remains with the economic operator or its service provider. The Registry is an index and verification layer, not the central data store for every visible passport field.

Article 14 of the ESPR additionally requires a public web portal through which stakeholders can search and compare DPP data according to their access rights. As of 21 July 2026, a documented public search journey has not yet been published. For now, the reliable access route is therefore a known carrier or product identifier.

The new Registry Implementing Regulation specifies registration, validation, semantics, security and APIs, but it does not provide a consumer guide for browsing real product passports.

Preparing a DPP QR code correctly: a practical checklist

1. Determine the product-specific measure, carrier placement and passport granularity.
2. Inventory existing GTINs, batch numbers, serial numbers and internal identifiers.
3. Choose the UPI scheme and test collisions, variants and lifecycle scenarios.
4. Decide whether a direct URI is sufficient or a resolver should manage multiple resources.
5. Secure domain ownership, HTTPS, redirects and long-term responsibility.
6. Model public, role-specific and machine-readable views separately.
7. Test QR or another carrier on the real substrate, at production size and after ageing.
8. Provide the same access route to e-commerce, marketplaces, service and spare-parts processes.
9. Monitor broken links, incorrect redirects and unavailable passport data.
10. Register in the EU Registry only after the DPP is hosted, complete and technically validatable.

What is clear in July 2026—and what is still missing?

Companies can prepare identifier inventories, domain strategy, resolver architecture, data ownership and scanning journeys now. They should not claim that an arbitrary GS1 QR code is already fully EU-compliant for every product group. The implementation roadmap separates robust preparation from decisions that must wait for the applicable measure.

Official foundations for DPP access and QR codes

• ESPR – Regulation (EU) 2024/1781, especially Articles 10, 11 and 14
• Implementing Decision (EU) 2026/1736 listing six harmonised DPP standards
• European Commission DPP Registry information page
• DPP Registry User Guide for Economic Operators, version 1.0, 51 pages
• GS1 Digital Link standard and current versions
• GS1 Germany – product identification with GS1 Digital Link