What Is a DPP Resolver and Why Is It Critical?

The Missing Piece Most Brands Overlook

When brands begin thinking about Digital Product Passport implementation, two components get most of the attention: the data (what information needs to be in the passport) and the data carrier (the QR code or RFID tag a consumer scans). Both matter. But between these two components lies a third, less discussed element that makes the whole system function — the resolver.

Without a resolver, a QR code on a garment is nothing more than a hyperlink. With a resolver, it becomes a gateway to a structured, standards-compliant, stakeholder-specific data interface. Understanding what a resolver is — and what it demands from your infrastructure — is essential for any brand serious about DPP compliance under the EU's Ecodesign for Sustainable Products Regulation (ESPR).

What a Resolver Actually Does

The resolver is an online service that maintains a registry of product identifiers and maps each one to the location where its DPP data is stored.

Here is the basic sequence of events when a product's data carrier is scanned:

1. A consumer, regulator, or recycler scans the QR code (or reads the RFID/NFC tag) on a garment.
2. The scan reads a unique identifier — typically a serialized Global Trade Identification Number (GTIN) encoded in GS1 Digital Link format.
3. That identifier is sent to the resolver.
4. The resolver looks up the identifier in its registry and determines: where is the DPP data for this specific product unit stored?
5. The resolver redirects the request to the correct data endpoint — which may be your brand's own DPP platform, a third-party DPP service provider, or a certified data registry.
6. The requester receives the DPP data appropriate to their access level (consumer-visible data, restricted regulatory data, or circular economy operator data).

This process happens in seconds. To the end user it is invisible. But it is architecturally foundational — without it, the whole system breaks down.

A resolver is not a database. It does not store DPP data itself. It stores the address of where that data lives — and routes incoming requests to the right place. This distinction reflects the ESPR requirement for decentralized data storage: data stays with the entity that created it, while the resolver enables it to be found.

Why This Architecture Matters for Compliance

ESPR does not permit a simple model in which all DPP data is aggregated in a single centralized database operated by the European Commission or any other authority. The regulation explicitly requires decentralized data storage: data must be held and managed by the entity responsible for creating it — the brand, or a certified third-party service provider acting on the brand's behalf.

This design choice has important implications:

• Responsibility stays with the source. The brand that places a product on the EU market (the Responsible Economic Operator) is accountable for the accuracy of its DPP data. Decentralized storage means there is no intermediary that could introduce errors or degrade the data — the brand controls what is stored and how.
• Interoperability becomes critical. Because data is distributed across many different systems — different brands using different platforms and data providers — the resolver must operate using open, standardized protocols so that any compliant system can communicate with any other.
• A diverse commercial market can develop. By preventing centralization, ESPR creates space for multiple DPP service providers to offer competing solutions. Brands are not locked into a single government-run database.

The resolver is what makes decentralization workable. Without it, decentralized storage would mean fragmented, inaccessible data. With it, any authorized stakeholder can reach the right data regardless of which platform it is stored on.

GS1 Digital Link: The Standard Enabling the Resolver

For the resolver to work, product identifiers must follow a consistent, machine-readable standard that any compliant resolver can interpret. The standard ESPR points toward is GS1 Digital Link.

GS1 Digital Link is a web URI standard that encodes structured product identity data — including the product type (GTIN) and a unique serial number — into a single URL-compatible string. When this string is encoded into a QR code and scanned, the resolver reads it and can extract both pieces of information:

• What type of product is this? (the GTIN identifies the product model)
• Which specific individual unit is this? (the serial number identifies the unique item)

This two-part identity — product type plus individual serialization — is fundamental to the DPP model. Every individual garment must have its own unique identifier, not just every style or SKU. Two identical t-shirts on the same production line must carry different identifiers and can theoretically carry different DPP data (if, for example, one was later repaired and its composition changed).

The GS1 Digital Link resolver is already operational and can handle both standard product hierarchies and non-standard product structures, making it adaptable to the varied ways textile brands organize their product ranges.

Routing Different Stakeholders to Different Data

One of the resolver's most important functions is enabling differentiated data access — serving different information to different stakeholders who scan the same product code.

Under ESPR, not all DPP data is visible to all parties. The regulation distinguishes between:

• Public data — accessible to consumers and the general public. Care instructions, basic material composition, sustainability certifications, and repair guidance.
• Restricted regulatory data — accessible to customs authorities, market surveillance bodies, and regulators. Detailed chemical compliance records, supply chain facility identifiers, conformity declarations.
• Circular economy operator data — accessible to repairers, recyclers, and remanufacturers. Component-level material composition, disassembly instructions, hazardous substance locations.

A sophisticated resolver — or the DPP data platform it connects to — can read the identity of the requesting party and return the appropriate data layer. A consumer scanning from a retail environment sees one view. A customs officer using an authorized market surveillance tool sees a different view of the same product record. A recycler processing end-of-life goods sees a third.

This access differentiation is not optional. Publishing restricted chemical compliance data to general consumers, or failing to provide recyclers with the material detail they need, are both compliance failures under ESPR.

Operational Implications for Brands

Understanding the resolver's role has direct consequences for how brands need to think about their DPP infrastructure:

You Need a Data Endpoint, Not Just a Data File

The resolver does not serve data — it routes to a URL where data is served. Your brand needs to have a stable, accessible API endpoint (or a certified third-party service) that can receive resolver-routed requests and return the correct data. A product information PDF, a static webpage, or a shared drive folder is not an adequate data endpoint for DPP purposes.

Your Data Endpoint Must Be Persistent

The resolver maps identifiers to data locations. If your data endpoint URL changes — because you switch platforms, restructure your website, or migrate data — the resolver registry must be updated to match. Products already in circulation that carry the old identifier encoded in their QR codes will break if the endpoint they resolve to disappears.

This is a longer-term operational consideration that many brands underestimate during initial implementation planning. A product placed on market in 2028 could still be in active circulation in 2040. Its DPP data endpoint must remain accessible throughout.

Serialized Identifier Generation Must Be Managed Upstream

For the resolver to function, every product entering the market must already have a unique serialized identifier generated and registered before it reaches the consumer. This means identifier generation must be integrated into your production workflow — typically at the point of label printing in the CMT facility — and each identifier must be registered in the resolver registry before the product is shipped.

This introduces a data dependency between your DPP platform and your garment label production process that requires careful operational design and supplier coordination.

The Technical Standards Picture

The precise technical specifications for resolver infrastructure under ESPR are being developed by the European standardization bodies CEN and CENELEC, with harmonized standards expected by the end of 2025. These standards will define the exact protocols, API formats, and interoperability requirements that compliant resolver services must meet.

The direction of travel is clear even before the final standards are published:

• Open standards and open-source protocols — no proprietary lock-in
• GS1 Digital Link as the primary identifier encoding standard
• RESTful API-based data exchange
• JSON-LD or similar machine-readable data formats
• Authentication and access control mechanisms for restricted data layers

Brands that select DPP service providers now should verify that their provider's resolver infrastructure is built on open standards and will be certifiable under the CEN/CENELEC technical standards when they are published. Proprietary resolver solutions that cannot demonstrate standards alignment will create migration risk and potential non-compliance as enforcement approaches.

The Backup Registry Requirement

ESPR includes an important provision that directly relates to resolver infrastructure: a backup copy of all DPP data must be maintained by a certified independent third-party provider.

This requirement exists to protect the durability of the DPP system. If a brand ceases to operate, is acquired, or its DPP platform provider shuts down, the data associated with products already on the market must remain accessible. The backup registry ensures that the resolver can still route requests to valid data even if the primary data holder is no longer active.

For brands planning their DPP infrastructure, this means verifying that their chosen DPP provider has a certified backup arrangement in place — and understanding what happens to their product data if they ever change providers.

What to Do Now

The resolver is not something a brand builds itself — it is infrastructure provided by a DPP service provider or, in future, potentially by EU-level standardized services. But there are steps brands can take now to ensure they are resolver-ready:

• Ensure your product identifiers follow GS1 standards. If your products already use GTINs, you have a strong foundation. Confirm that your current coding scheme is compatible with GS1 Digital Link serialization.
• Evaluate DPP service providers on resolver capability. When assessing potential DPP platforms, ask specifically about their resolver infrastructure: Is it based on open standards? Is it registered with GS1? How is it backed up? How are identifier registrations managed?
• Plan for persistent data endpoints. Think about how you will maintain data accessibility over the full lifecycle of products you place on market — not just through your next product refresh cycle.
• Integrate serialization into your production planning. The resolver cannot function if product identifiers are not generated and registered before products enter the market. Start planning the production workflow changes needed to make this happen.

Frequently Asked Questions

Can a brand build and operate its own resolver?

Technically yes — but practically, operating a resolver requires adherence to open standards, ongoing maintenance, high availability, and eventually certification under the CEN/CENELEC technical standards. Most brands will be better served by using a certified DPP service provider that operates a compliant resolver as part of their platform. The important thing is that whichever resolver your brand uses, it must be standards-compliant and interoperable with the broader ESPR ecosystem.

What happens if the resolver goes down?

Resolver availability is a critical system requirement. Any resolver used in a compliant DPP system must meet high availability standards — a resolver that goes down means product data becomes inaccessible, which is a compliance failure. This is one reason the backup registry requirement matters: it provides a fallback for data retrieval even if the primary resolver is temporarily unavailable.

Does a resolver work differently for RFID versus QR codes?

The resolver logic is the same regardless of data carrier type. Whether the unique identifier reaches the resolver via a QR code scan, an NFC tap, or an RFID read, the resolver receives the same identifier string and performs the same lookup and routing function. The data carrier choice affects how the identifier is physically presented and read — it does not change the resolver's role in the system.