DPP vs GS1 Digital Link legal duties vs resolver standards
The EU Digital Product Passport is a regulatory information and access-rights framework under ESPR. GS1 Digital Link is the GS1 standard for representing GS1 identification keys in Web URIs; resolver behavior is covered by a separate GS1 standard.
This comparison helps keep legal DPP requirements separate from technical identifier, barcode, and resolver implementation choices.
DPP and are often discussed together because both can connect a product identifier in a data carrier to online information. They are not interchangeable. ESPR defines when a passport is required, its data and access rights, registry and portal integration, and economic-operator responsibility. The current GS1 Digital Link standard defines URI syntax for GS1 identification keys. A separate GS1-Conformant Resolver standard defines how one identifier can lead to multiple information resources. Neither standard defines ESPR passport content or replaces a delegated act.
Comparison matrix
DPP vs GS1 Digital Link: what each one controls
The rows below separate legal passport obligations from identifier and resolver implementation standards so product, compliance, packaging, data, and IT teams do not treat a QR code as proof of DPP compliance.
A product-passport obligation under ESPR when an applicable delegated act requires it, including passport data, access rights, unique identifiers, data carriers, registry, portal, customs, and availability requirements.
Second framework
GS1 Digital Link
A GS1 URI-syntax standard for representing GS1 identification keys such as GTIN in Web addresses. Resolution to one or more related resources is specified separately by the GS1-Conformant Resolver standard.
DPP is a legal compliance construct under ESPR. Products may only be placed on the market or put into service with a passport when the applicable delegated act requires one, and the passport data must be accurate, complete, and up to date.
is not DPP law. It is the GS1 URI-syntax standard for representing GS1 identification keys in Web addresses. Resolver-enabled discovery is related but governed by the separate GS1-Conformant Resolver standard.
Treat as a possible technical layer inside a DPP design, not as a replacement for the delegated act, required passport data, access rights, registry upload, or compliance evidence.
DPP scope depends on ESPR delegated acts for product groups. Those acts specify the covered products, data to include, data carrier, layout and positioning, passport granularity, accessible pre-sale information, access actors, update actors, update arrangements, and availability period.
can be used by product teams before or outside an ESPR DPP trigger. Its scope follows GS1 identifier and application rules, not the ESPR product-group trigger.
Start DPP scoping with the product group and delegated act. Then decide whether a URI can carry or resolve the identifier design for that scoped product.
A DPP must be connected through a data carrier to a persistent unique product identifier. ESPR allows the delegated act to set whether the passport is established at model, batch, or item level.
commonly starts from GS1 identifiers such as GTIN and can add attribute data in the URI. GS1 specifications distinguish class-level, sub-class-level, and instance-level identifiers, but the DPP granularity still has to match the delegated act.
Do not assume a GTIN-only design is enough for every DPP. If the DPP must operate at batch or item level, the identifier, URI path, barcode content, resolver records, and source systems must preserve that granularity.
ESPR requires the data carrier to be physically present on the product, packaging, or accompanying documentation as the delegated act specifies. It must connect the physical product to the persistent identifier and passport access route.
can be encoded in QR Code or Data Matrix and may also be relevant for NFC. GS1 describes it as explicitly encoding a resolvable Web URI rather than only a direct product number.
A DPP label decision must cover physical placement, durability, pre-sale digital access, scanner behavior, and reliable resolution for consumers and professional users.
DPP data is the regulated product information set. It must use open standards and interoperable formats and be machine-readable, structured, searchable, and transferable where appropriate without vendor lock-in.
does not define the ESPR passport data set. It gives a standard way to encode GS1 data into a URI and route users or systems toward resources that the brand owner or service provider makes available.
Use a data model and evidence process for the passport itself. Use , if selected, to reach that data or related resources without pretending the URI syntax supplies the required DPP content.
ESPR requires access to DPP data to be regulated by actor-specific access rights. It names customers, economic operators, repairers, recyclers, market surveillance authorities, customs authorities, civil society, trade unions, and other relevant actors.
A GS1-Conformant Resolver can link one identified entity to multiple information resources. It does not supply ESPR authorization rules; the DPP system must enforce credentials and role-specific access under the applicable delegated act.
Design public, business, authority, repair, recycling, and update paths separately. A single public landing page reached from a URI is not the same as a role-aware DPP access model.
ESPR creates Commission-managed DPP infrastructure: a registry that stores at least unique identifiers and, for customs release for free circulation, commodity code data; a public web portal to search and compare passport data; and customs verification through registry interconnection.
is not the EU DPP registry, web portal, or customs system. A resolver can help discovery, but it does not automatically upload identifiers, obtain a unique registration identifier, support the EU portal, or satisfy customs registry checks.
Implementation plans need separate work packages for GS1 identifier and resolver governance, EU registry upload, unique registration identifier handling, portal discoverability, and customs data alignment.
ESPR requires DPP storage by the responsible economic operator or a digital product passport service provider, a backup copy, and availability for the period specified in delegated acts, including after insolvency, liquidation, or cessation of activity in the Union.
persistence depends on identifier governance, domain and resolver operation, and link maintenance. GS1 rules and CIRPASS architecture material both make clear that resolvable URIs and resolver records need operational stewardship.
Do not let the marketing domain or packaging code become the only persistence plan. Preserve ownership of identifiers, domains, resolver records, backup access, and service-provider handover before products enter the market.
implementation starts with identifier governance and resolution: GS1 keys and attributes, URI syntax, barcode or NFC encoding, resolver records, link types, domain stewardship, scanner behavior, and routing to public or restricted resources.
The useful architecture is a crosswalk, not a substitution. Map each DPP obligation to the system component that fulfils it, then mark which components can support and which must be handled elsewhere.
DPP is a legal compliance construct under ESPR. Products may only be placed on the market or put into service with a passport when the applicable delegated act requires one, and the passport data must be accurate, complete, and up to date.
is not DPP law. It is the GS1 URI-syntax standard for representing GS1 identification keys in Web addresses. Resolver-enabled discovery is related but governed by the separate GS1-Conformant Resolver standard.
Treat as a possible technical layer inside a DPP design, not as a replacement for the delegated act, required passport data, access rights, registry upload, or compliance evidence.
DPP scope depends on ESPR delegated acts for product groups. Those acts specify the covered products, data to include, data carrier, layout and positioning, passport granularity, accessible pre-sale information, access actors, update actors, update arrangements, and availability period.
can be used by product teams before or outside an ESPR DPP trigger. Its scope follows GS1 identifier and application rules, not the ESPR product-group trigger.
Start DPP scoping with the product group and delegated act. Then decide whether a URI can carry or resolve the identifier design for that scoped product.
A DPP must be connected through a data carrier to a persistent unique product identifier. ESPR allows the delegated act to set whether the passport is established at model, batch, or item level.
commonly starts from GS1 identifiers such as GTIN and can add attribute data in the URI. GS1 specifications distinguish class-level, sub-class-level, and instance-level identifiers, but the DPP granularity still has to match the delegated act.
Do not assume a GTIN-only design is enough for every DPP. If the DPP must operate at batch or item level, the identifier, URI path, barcode content, resolver records, and source systems must preserve that granularity.
ESPR requires the data carrier to be physically present on the product, packaging, or accompanying documentation as the delegated act specifies. It must connect the physical product to the persistent identifier and passport access route.
can be encoded in QR Code or Data Matrix and may also be relevant for NFC. GS1 describes it as explicitly encoding a resolvable Web URI rather than only a direct product number.
A DPP label decision must cover physical placement, durability, pre-sale digital access, scanner behavior, and reliable resolution for consumers and professional users.
DPP data is the regulated product information set. It must use open standards and interoperable formats and be machine-readable, structured, searchable, and transferable where appropriate without vendor lock-in.
does not define the ESPR passport data set. It gives a standard way to encode GS1 data into a URI and route users or systems toward resources that the brand owner or service provider makes available.
Use a data model and evidence process for the passport itself. Use , if selected, to reach that data or related resources without pretending the URI syntax supplies the required DPP content.
ESPR requires access to DPP data to be regulated by actor-specific access rights. It names customers, economic operators, repairers, recyclers, market surveillance authorities, customs authorities, civil society, trade unions, and other relevant actors.
A GS1-Conformant Resolver can link one identified entity to multiple information resources. It does not supply ESPR authorization rules; the DPP system must enforce credentials and role-specific access under the applicable delegated act.
Design public, business, authority, repair, recycling, and update paths separately. A single public landing page reached from a URI is not the same as a role-aware DPP access model.
ESPR creates Commission-managed DPP infrastructure: a registry that stores at least unique identifiers and, for customs release for free circulation, commodity code data; a public web portal to search and compare passport data; and customs verification through registry interconnection.
is not the EU DPP registry, web portal, or customs system. A resolver can help discovery, but it does not automatically upload identifiers, obtain a unique registration identifier, support the EU portal, or satisfy customs registry checks.
Implementation plans need separate work packages for GS1 identifier and resolver governance, EU registry upload, unique registration identifier handling, portal discoverability, and customs data alignment.
ESPR requires DPP storage by the responsible economic operator or a digital product passport service provider, a backup copy, and availability for the period specified in delegated acts, including after insolvency, liquidation, or cessation of activity in the Union.
persistence depends on identifier governance, domain and resolver operation, and link maintenance. GS1 rules and CIRPASS architecture material both make clear that resolvable URIs and resolver records need operational stewardship.
Do not let the marketing domain or packaging code become the only persistence plan. Preserve ownership of identifiers, domains, resolver records, backup access, and service-provider handover before products enter the market.
implementation starts with identifier governance and resolution: GS1 keys and attributes, URI syntax, barcode or NFC encoding, resolver records, link types, domain stewardship, scanner behavior, and routing to public or restricted resources.
The useful architecture is a crosswalk, not a substitution. Map each DPP obligation to the system component that fulfils it, then mark which components can support and which must be handled elsewhere.
How should teams use GS1 Digital Link in a DPP program?
Use ESPR and the relevant delegated act to decide whether a passport is required, which product level applies, what data is mandatory, who can access or update it, and how registry and customs integration must work.
Use only where the identifier, data carrier, URI, and resolver design fits the DPP requirements and the organization's product-identification governance.
Keep a crosswalk that separates DPP legal requirements from GS1 implementation choices: identifier source, encoded value, resolver owner, link targets, access categories, registry fields, backup route, and evidence owner.
This comparison matters when packaging, master-data, sustainability, compliance, and IT teams are deciding whether the same QR code or resolver can serve both product-identification and EU DPP access needs.
A URI can identify a product in a Web address, and a conformant resolver can connect that identifier to multiple resources. DPP implementation still needs the regulated passport data set, actor-specific access controls, update rights, registry upload, web-portal discoverability, customs integration where relevant, and long-term availability. The Commission launched the DPP Registry and a testing environment on 20 July 2026.
Use the DPP side to define legal scope, passport content, access categories, registry fields, and evidence ownership.
Use the side to define identifier syntax, barcode or NFC content, resolver behavior, link types, and domain operations.
Escalate designs that rely only on a public marketing page, a GTIN-only identifier, or an unmanaged domain redirect for a product that needs a regulated DPP.
This comparison helps build a DPP implementation crosswalk that shows which legal requirements are satisfied by the passport data model, which are supported by GS1 Digital Link, and which require registry, portal, access-control, or customs integration work.
Architecture source for resolver-based access, UID-to-URI transformation, decentralized DPP repositories, and separation between access route and DPP data.
Current GS1 standard for resolving an identified entity to one or more machine-discoverable information resources; it does not define ESPR access rights.