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. 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.
Supports the DPP side: ESPR makes passport availability and data quality legal requirements when a delegated act requires a DPP.
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.
Current GS1 landing page distinguishing Digital Link URI syntax from the separate resolver and compression standards.
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.
Lists the DPP elements that delegated acts must specify for covered product groups.
specify the following
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.
Shows that GS1 Digital Link belongs to GS1 application and syntax rules rather than ESPR product-group scoping.
GS1 Digital Link Standard: URI syntax
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.
Supports the DPP requirement for a persistent unique product identifier and delegated-act granularity.
model, batch or item
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.
Defines GS1 identifier levels and describes Digital Link URI syntax with GTIN and attribute data.
GTIN and attribute data
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.
Explains that DPP designers should choose model, batch, or item granularity and then select product, operator, registry, facility, and other identifiers.
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.
Supports physical data-carrier placement requirements under ESPR.
physically present on the product
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.
Supports QR Code, Data Matrix, NFC, and resolvable URI behavior for GS1 Digital Link.
explicitly encodes a resolvable Web URI
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.
Supports open-standard, interoperable, machine-readable, searchable, transferable DPP data requirements.
open interoperable data exchange network
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.
Supports that GS1 Digital Link is about URI syntax and encoded GS1 data rather than ESPR passport data categories.
GS1 DL URI
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.
Supports named actor categories and free, easy access based on delegated-act access rights.
based on their respective access rights
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.
Current GS1 standard for resolving an identified entity to one or more machine-discoverable information resources; it does not define ESPR access rights.
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.
Supports registry, web portal, and customs-control obligations for DPP infrastructure.
publicly accessible web portal
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.
Describes GS1 Digital Link-inspired HTTP URI architecture as one route from product identifier to resolver, separate from EU registry functions.
points to a resolver
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.
Supports DPP storage, backup, and continuity requirements after economic-operator disruption.
including after an insolvency
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.
Supports the need to maintain records and follow GS1 allocation and non-reuse rules when GS1 identification ownership changes.
maintain records of all GS1 identification keys
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.
Supports the core DPP implementation components: data, access rights, update rights, registry, portal, customs, and technical design.
Technical design and operation
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.
Supports GS1 Digital Link implementation components: GS1 data, URI syntax, data carriers, and GS1 standard references.
QR Code or Data Matrix
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.
Supports the practical crosswalk approach by separating product identifier discovery routes from the underlying interoperable DPP data.
Whatever means are used to access
Scope boundary
EU Digital Product Passport
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.
Supports the DPP side: ESPR makes passport availability and data quality legal requirements when a delegated act requires a DPP.
accurate, complete and up to date
GS1 Digital Link
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.
Current GS1 landing page distinguishing Digital Link URI syntax from the separate resolver and compression standards.
Operational implication
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.
ESPR assigns DPP details to delegated acts, so a technical link standard alone cannot determine legal passport compliance.
as specified in the delegated act
Product scope and legal trigger
EU Digital Product Passport
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.
Lists the DPP elements that delegated acts must specify for covered product groups.
specify the following
GS1 Digital Link
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.
Shows that GS1 Digital Link belongs to GS1 application and syntax rules rather than ESPR product-group scoping.
GS1 Digital Link Standard: URI syntax
Operational implication
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.
DPP design guidance says DPP information categories and methods should be determined by the product-specific delegated act.
determined in the specific delegated act
Identifier level and URI design
EU Digital Product Passport
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.
Supports the DPP requirement for a persistent unique product identifier and delegated-act granularity.
model, batch or item
GS1 Digital Link
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.
Defines GS1 identifier levels and describes Digital Link URI syntax with GTIN and attribute data.
GTIN and attribute data
Operational implication
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.
Explains that DPP designers should choose model, batch, or item granularity and then select product, operator, registry, facility, and other identifiers.
Product Model
Physical carrier and placement
EU Digital Product Passport
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.
Supports physical data-carrier placement requirements under ESPR.
physically present on the product
GS1 Digital Link
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.
Supports QR Code, Data Matrix, NFC, and resolvable URI behavior for GS1 Digital Link.
explicitly encodes a resolvable Web URI
Operational implication
A DPP label decision must cover physical placement, durability, pre-sale digital access, scanner behavior, and reliable resolution for consumers and professional users.
Guidance compares QR codes, DataMatrix, RFID, NFC, and related characteristics for DPP data-carrier selection.
QR codes, DataMatrixes, passive RFID tags
Passport content and URI syntax
EU Digital Product Passport
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.
Supports open-standard, interoperable, machine-readable, searchable, transferable DPP data requirements.
open interoperable data exchange network
GS1 Digital Link
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.
Supports that GS1 Digital Link is about URI syntax and encoded GS1 data rather than ESPR passport data categories.
GS1 DL URI
Operational implication
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.
CIRPASS separates the access route from DPP data and highlights interoperable data formats for the passport itself.
DPP Data itself remains the same
Access rights and role control
EU Digital Product Passport
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.
Supports named actor categories and free, easy access based on delegated-act access rights.
based on their respective access rights
GS1 Digital Link
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.
Current GS1 standard for resolving an identified entity to one or more machine-discoverable information resources; it does not define ESPR access rights.
Operational implication
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.
Supports restricted rights to introduce, modify, or update passport data.
introduce, modify or update data
Registry, portal and customs integration
EU Digital Product Passport
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.
Supports registry, web portal, and customs-control obligations for DPP infrastructure.
publicly accessible web portal
GS1 Digital Link
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.
Describes GS1 Digital Link-inspired HTTP URI architecture as one route from product identifier to resolver, separate from EU registry functions.
points to a resolver
Operational implication
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.
Guidance identifies the EU central registry and EU DPP web portal as systems DPPs should be linked to.
EU central registry and the EU DPP web portal
Persistence and provider handover
EU Digital Product Passport
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.
Supports DPP storage, backup, and continuity requirements after economic-operator disruption.
including after an insolvency
GS1 Digital Link
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.
Supports the need to maintain records and follow GS1 allocation and non-reuse rules when GS1 identification ownership changes.
maintain records of all GS1 identification keys
Operational implication
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.
Supports the core DPP implementation components: data, access rights, update rights, registry, portal, customs, and technical design.
Technical design and operation
GS1 Digital Link
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.
Supports GS1 Digital Link implementation components: GS1 data, URI syntax, data carriers, and GS1 standard references.
QR Code or Data Matrix
Operational implication
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.
Supports the practical crosswalk approach by separating product identifier discovery routes from the underlying interoperable DPP data.
Whatever means are used to access
Practical decision rule
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.
Architecture source for resolver-based access, UID-to-URI transformation, decentralized DPP repositories, and separation between access route and DPP data.
From Data Carrier to a Usable URI
1
Section 1
When the comparison matters
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.
Current official source confirming launch of the DPP Registry and testing environment on 20 July 2026.
Recommended next step
Separate DPP obligations from identifier design
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.
Primary legal source for EU Digital Product Passport scope, passport content, data carriers, persistent unique identifiers, access rights, registry, web portal, customs controls, storage, backup, and availability.
Supports the legal DPP requirements that go beyond simply placing a scannable code on a product.
Supports the DPP side: ESPR makes passport availability and data quality legal requirements when a delegated act requires a DPP.
Show 12 more
ESPR assigns DPP details to delegated acts, so a technical link standard alone cannot determine legal passport compliance.
Lists the DPP elements that delegated acts must specify for covered product groups.
Supports the DPP requirement for a persistent unique product identifier and delegated-act granularity.
Supports physical data-carrier placement requirements under ESPR.
Supports open-standard, interoperable, machine-readable, searchable, transferable DPP data requirements.
Supports named actor categories and free, easy access based on delegated-act access rights.
Supports restricted rights to introduce, modify, or update passport data.
Supports registry, web portal, and customs-control obligations for DPP infrastructure.
Supports DPP storage, backup, and continuity requirements after economic-operator disruption.
Supports the requirement that the passport remain available for the period specified by delegated acts.
Supports the core DPP implementation components: data, access rights, update rights, registry, portal, customs, and technical design.
Primary legal source for DPP requirements, delegated-act scoping, data carriers, unique identifiers, access rights, registry, portal, customs, storage, and availability.
Primary GS1 source for Digital Link URI syntax references, GTIN and GS1 identifier governance, data-carrier terminology, QR Code, Data Matrix, NFC, and related application rules.
Supports the GS1 implementation focus on GS1 identifiers, URI syntax, data carriers, and message-processing rules.
Shows that GS1 Digital Link belongs to GS1 application and syntax rules rather than ESPR product-group scoping.
Show 6 more
Defines GS1 identifier levels and describes Digital Link URI syntax with GTIN and attribute data.
Supports QR Code, Data Matrix, NFC, and resolvable URI behavior for GS1 Digital Link.
Supports that GS1 Digital Link is about URI syntax and encoded GS1 data rather than ESPR passport data categories.
Supports the need to maintain records and follow GS1 allocation and non-reuse rules when GS1 identification ownership changes.
Supports GS1 Digital Link implementation components: GS1 data, URI syntax, data carriers, and GS1 standard references.
Primary GS1 source for Digital Link URI syntax references, GS1 identifiers, data carriers, and related application rules.
DPP design guidance source for identifier options, data-carrier choices, DPP information portal setup, searchability, information exchange management, traceability, and lifecycle availability.
Supports DPP design choices for data carriers, portal setup, searchability, exchange management, traceability, and lifecycle availability.
DPP design guidance says DPP information categories and methods should be determined by the product-specific delegated act.
Show 3 more
Explains that DPP designers should choose model, batch, or item granularity and then select product, operator, registry, facility, and other identifiers.
Guidance compares QR codes, DataMatrix, RFID, NFC, and related characteristics for DPP data-carrier selection.
Guidance identifies the EU central registry and EU DPP web portal as systems DPPs should be linked to.
Architecture source for DPP access using HTTP URIs, GS1 Digital Link-inspired resolver flows, UID-to-URI transformation, decentralized repositories, role-based access, and EU registry interactions.
CIRPASS separates the access route from DPP data and highlights interoperable data formats for the passport itself.
Describes GS1 Digital Link-inspired HTTP URI architecture as one route from product identifier to resolver, separate from EU registry functions.
Show 3 more
Explains UID-to-URI transformation, resolver use, and caution around domain-name transfer and archive access.
Supports the practical crosswalk approach by separating product identifier discovery routes from the underlying interoperable DPP data.
Architecture source for resolver-based access, UID-to-URI transformation, decentralized DPP repositories, and separation between access route and DPP data.
Current GS1 source for resolving an identified entity to one or more related information resources.
Current GS1 standard for resolving an identified entity to one or more machine-discoverable information resources; it does not define ESPR access rights.