Ask a brand owner what their Digital Product Passport looks like and they'll often point you to a PDF. Or a QR code that links to a web page. Or a product detail page with a sustainability section bolted on.
That's not a DPP. And in 2027, a market surveillance officer will know the difference.
Picture the scene. A market surveillance officer walks into a distribution centre in Rotterdam. She picks up a garment. She scans the QR code on the label.
One of three things happens.
Either nothing loads — the URL is dead, or it redirects to a 404. Or a PDF opens. Or a structured, machine-readable Digital Product Passport page loads: tiered access, persistent hosting, API-queryable data, material composition right down to fibre origin.
The first two outcomes aren't close calls. They're compliance failures.
The gap between them isn't a design problem. It's a data architecture problem. And it starts a long way upstream from any page you'd build.
Most brands focus on the wrong thing when they start thinking about DPP compliance. The consumer-facing page — what it looks like, how it's laid out — is genuinely the easiest part of this. You can build a DPP page in a day with the right tooling.
What you can't do quickly is fix fragmented product data.
Your material composition lives in your PLM. Your batch numbers and GTINs live in your ERP. Your product descriptions live in your PIM. None of these systems were built with the Ecodesign for Sustainable Products Regulation (ESPR) in mind. None of them export data in the formats the CEN/CENELEC technical standards require.
Before a DPP page can go live, you have to:
That four-step process is what a DPP implementation actually is. The page is what you put on top.
A consumer-facing Digital Product Passport page is a legally mandated structured data record. Under ESPR (EU Regulation 2024/1781), the required fields for textiles and apparel include:
The CEN/CENELEC technical standards tighten this further. Under prEN 18239, data must be tiered: public data freely accessible to consumers, restricted data gated for authorities and repair professionals. Under prEN 18221, the data must persist — your DPP page must remain accessible even if your brand changes hands or ceases to operate.
That last requirement is the one that catches most brands off guard. Hosting your DPP on your marketing website isn't enough. If your domain changes or your CMS breaks, you've violated EU persistence requirements before enforcement has even begun.
This is where most brands make their first serious technical mistake.
A GS1 Digital Link QR code doesn't encode a URL. It encodes structured product identifiers — primarily the Global Trade Item Number (GTIN) and optional serial or batch numbers — in a standardised web address format. A compliant code looks something like:
https://resolver.example.com/01/05012345678900
The 01 is the GS1 Application Identifier for a GTIN. The 14-digit string following it is the product identifier. When a consumer scans this code, the request hits a GS1 Resolver — an intelligent routing layer that evaluates the context of the scan and returns the right content.
A consumer scanning on a smartphone gets the public DPP page. A logistics scanner reading the same code pulls structured batch and routing data. A customs authority gets access to restricted compliance documentation. Same physical code, different responses, all determined by the resolver.
This routing architecture is what makes DPP QR codes fundamentally different from a web link embedded in a barcode. When your URL structure changes — and it will — every QR code on every physical product becomes a dead link. With a GS1 Resolver, you update the routing centrally. The codes remain valid indefinitely.
Hardcoding a web URL into a QR code is a compliance failure waiting to happen. It's also one of the most common mistakes we see.
The mistake we see most often: a brand takes an existing product information PDF, uploads it to their server, and encodes the link in a QR code.
It fails. Every time. Here's exactly why.
It's not machine-readable. ESPR and the CEN standard prEN 18222 require DPP data to be accessible via structured APIs — meaning a machine must be able to query it programmatically. A PDF is opaque to any automated system. Customs authorities, market surveillance bodies, and downstream supply chain partners can't extract data from it. This isn't a process risk. This is a market access risk.
It can't implement tiered access. EU regulations distinguish between data accessible to consumers, data accessible to repair professionals, and data accessible to authorities. A PDF has one access mode: everyone sees everything, or no one does. That structure doesn't satisfy prEN 18239.
It can't be updated dynamically. A DPP is a living record. It must reflect the product's actual current state — updated sustainability certifications, batch-specific data, revised recycling instructions. A PDF is static by definition. The moment anything changes, your compliance record is wrong.
A compliant DPP page is a structured data endpoint with a consumer-friendly presentation layer on top. Not a document. Not a link. A queryable record.
Here's what building DPP pages properly actually looks like.
Step 1 — Aggregate from source systems. Your PLM contributes material and design data. Your ERP contributes GTINs, batch numbers, serial numbers, and supply chain event data. Your PIM contributes product descriptions and attributes already reviewed for accuracy. The challenge is that none of these systems speak the same language — you need a mapping layer that translates each feed into the EPRS 16-category DPP data model.
Step 2 — Validate and structure. The DPP platform ingests this data and validates it against the EPCIS 2.0 event model and the specific delegated act rules for your product category. This is where data gaps become visible. A field your PLM team assumed was optional turns out to be mandatory for textiles compliance. Better to find that out during implementation than during a market surveillance audit.
Step 3 — Configure the resolver and generate Digital Link URIs. The platform creates GS1 Digital Link-compliant identifiers for each product, batch, or serialised item, and configures the resolver routing rules. The link types define what each scanner receives: gs1:pip for the consumer product information page, machine-readable endpoints for automated systems.
Step 4 — Publish the DPP page. The consumer-facing page goes live — presenting required regulatory data in a readable format, implementing tiered access for restricted data, backed by a persistent data store that satisfies prEN 18221 rather than your marketing CMS.
TrackVision AI's DPP Page Builder is built to automate exactly this pipeline. The alternative is building it yourself: engineering custom integrations with each source system, building your own resolver, and maintaining everything as delegated act requirements evolve.
The delegated acts for textiles and apparel are finalised as of 2026. Mandatory enforcement is expected to begin mid-to-late 2027.
That sounds like time. It isn't.
The typical implementation timeline for a brand connecting PLM, ERP, and PIM to a DPP platform — including data quality remediation — runs 3 to 6 months for a well-prepared organisation. For brands starting from a fragmented data position, 12 months is realistic.
If your target compliance date is mid-2027 and you haven't started, you're already behind the schedule you need to be on.
Some of the brands building DPP pages are finding they're more useful than the regulation requires.
Every DPP page is a direct-to-consumer touchpoint on every physical product you sell. Brands are embedding care instructions, warranty registration links, authenticity verification, and sustainability storytelling alongside the mandatory compliance data. The QR code that regulators required you to print turns out to be the most reliable way to connect a physical product to a digital brand experience at scale.
That's not a compliance burden. That's a new channel — one that reaches every customer who touches the product, not just the ones who visit your website.
What is a consumer-facing DPP page?
A consumer-facing Digital Product Passport (DPP) page is a publicly accessible digital record containing verified product lifecycle data — including material composition, environmental impact, circularity information, and substances of concern. Under ESPR, this page must be linked to the physical product via a GS1 Digital Link QR code, must be machine-readable via structured API, and must be persistently hosted according to prEN 18221.
What's the difference between a GS1 Digital Link and a regular QR code?
A regular QR code encodes a static URL. A GS1 Digital Link QR code encodes structured product identifiers (such as a GTIN) into a standardised web address that routes through a GS1 Resolver. The resolver returns different content depending on who is scanning — a consumer gets the public DPP page, a logistics system gets structured batch data, an authority gets compliance documentation. This routing layer is what makes the code dynamically updatable and EU-compliant.
Why can't I just link my QR code to a PDF?
A PDF fails ESPR compliance on three grounds: it is not machine-readable via API (required by prEN 18222), it cannot implement tiered access for different user types (required by prEN 18239), and it cannot be updated dynamically as the product moves through its lifecycle. A compliant DPP page is a structured data endpoint — not a document.
What systems do I need to integrate to build a DPP page?
Most brands need to pull data from three source systems: PLM (material composition and design specifications), ERP (unique identifiers, batch numbers, supply chain events), and PIM (product descriptions and attributes). A DPP platform like TrackVision AI aggregates this data, validates it against ESPR delegated act requirements, and publishes it as a compliant, API-queryable DPP page.
What is prEN 18221 and why does it matter for DPP pages?
prEN 18221 is the CEN/CENELEC technical standard governing DPP data persistence and archiving. It requires DPP data to remain accessible even if the brand changes ownership or ceases to operate. A standard CMS or marketing website doesn't satisfy this requirement. The data must be backed by a persistent, independently hosted data store that can survive organisational changes — and that store must remain accessible for at least 10 years.
TrackVision AI's DPP Page Builder handles this entire pipeline — connecting your existing PLM, ERP, and PIM systems, mapping data to the EPRS 16-category DPP model, validating against ESPR delegated act requirements, and publishing GS1 Digital Link-compliant DPP pages without requiring your team to understand EPCIS 2.0.
The platform handles resolver configuration, generates compliant Digital Link URIs, and implements the tiered access model required by prEN 18239. Your sustainability and marketing teams can edit the consumer-facing presentation layer without touching the underlying compliance data structure.
If you're working out what it would take to go from your current product data to live DPP pages, we can run a readiness assessment and show you the specific gaps against your product category's delegated act — book 15 minutes.