The Digital Product Passport, seen from WooCommerce

A Digital Product Passport is a record attached to a product, opened by scanning a code on its label. The European Union created it in the 2024 ecodesign regulation, and is phasing it in one sector at a time.

Seen from a WooCommerce store, it is neither an IT project nor a compliance file. It is a product record, published at an address that does not move, with a code that leads to it. Most of the data it asks for is already in your catalogue, scattered between attributes, descriptions, and the label sewn into the garment.

This article reads the regulation from the admin screen: what it requires, what you already have, and what is left to decide.

What the regulation asks, in three pieces

Regulation (EU) 2024/1781, known as ESPR, sets the frame. Its article 10 comes down to three requirements, and they are simpler than their reputation.

A unique, persistent identifier. Every passport is named by an identifier that never changes, including when the product changes hands or your store changes platform. Persistent is the operative word: an identifier that vanishes with a deleted product page does not meet the condition.

A data carrier. A physical code ties the product to its passport. It goes on the product, on its packaging, or on the documentation that travels with it. The regulation names no specific technology: annex III points at the ISO/IEC 15459 family of standards, which a QR code, a Data Matrix, an RFID chip or an NFC tag all satisfy.

Accessible data. The passport has to be readable by several audiences, and they do not see the same thing. A customer, a repairer, a recycler and a market surveillance authority each have their own access rights. For a store, the public half is what matters: composition, origin, care, durability.

What the regulation does not do is worth noting too. It does not require GS1, GTINs, or any identifier vendor. Nor does it say which exact fields your sector will have to publish. That part arrives through delegated acts, and that is where the timing question really sits.

The EU registry does not hold your data

One point regularly surprises people: the central registry the Commission opened on 20 July 2026 does not store passports. It records the unique identifier, the commodity code, a reference to wherever the passport is hosted, and a timestamp.

In other words, the content stays with the operator placing the product on the market. That is good news for a self-hosted store: the data does not move into a third-party service, and the public passport page can live on your own domain.

Registering assumes a verified economic operator identity in the eIDAS sense. It is not a step to take while your sector has no delegated act.

What a passport actually looks like

The regulation describes requirements, not a layout. In practice a passport page fits on a phone screen, because that is where it gets opened: the customer scans the code in the shop, or while unwrapping the parcel.

What it shows, in reading order:

• the product name and the brand,
• the fibre composition in percentages, often carried by a bar that makes the proportions readable at a glance,
• the origin, meaning the country of manufacture and, where it is known, the production stage concerned,
• care instructions, taken from the sewn-in label,
• certifications and the batch number where they exist,
• the date it was last updated.

Two properties matter more than the content. The page has to open without an app, so it has to be an ordinary web page. And it has to outlive the product: if you delete the product from your store, the passport must not disappear with it, or the code printed on the garment leads your customer to an error.

That is the kind of detail nobody weighs when choosing a tool, and that decides everything three years later.

What your catalogue already holds

This is the part sector guides skip, because they address companies running an ERP. A WooCommerce store does not have that problem. It already has the data, filed in the wrong place.

So the useful work is not collecting new data. It is lifting composition out of descriptions into an attribute, then letting the values propagate.

A clothing store often sells the same fabric across dozens of references. Filling composition in once per category, then correcting only the exceptions, turns a catalogue of several hundred products into an afternoon of work. That is exactly what the DPTag defaults engine does: the product attribute wins, otherwise the category value, otherwise the store value.

Model, batch or item: the decision that shapes everything

The preparatory study published by the Commission's Joint Research Centre in May 2026 proposes three levels of granularity for textiles. They do not bind the final text, but they show the direction.

• Model level. Composition, environmental footprint, a durability score. This data is the same for every item of one reference.
• Batch level. Production sites, recycled content certificates. These change from one run to the next.
• Item level. An individual serial number. The study presents it as voluntary.

For a store, the consequence is direct: most of the data lives at model level. One passport per product reference is enough in the large majority of cases, and there is no question of serialising every item sold.

The same study makes another point worth reading: it notes that almost the whole European textile chain runs without heavy information systems, and explicitly recommends reusing existing commercial data rather than demanding new data.

What is not decided yet

This has to be stated plainly, because a lot of published material on the subject is not.

No textile delegated act exists today. There is no draft text to read. The Commission's indicative calendar puts its adoption in late 2027, with application roughly eighteen months later. The season dates circulating among some software vendors are commercial estimates, not official deadlines.

What is settled, by contrast, are the technical building blocks: six European standards covering identifiers, data carriers, storage persistence and interoperability were published in May 2026 and cited in the Official Journal in July. The calendar is covered in a separate article.

There is no exemption based on company size. The only size-based carve-out in the regulation concerns the ban on destroying unsold goods, which is a different subject.

What is reasonable to do now

Five moves, in this order. None of them needs a developer.

1. Get composition out of free text. Create a composition attribute and fill it in, starting with your broadest categories. This is the only real work, and it improves your product pages anyway.
2. Pick your granularity. Decide you publish at model level. You will revisit that for a specific range if a delegated act demands it, not before.
3. Publish at a stable address. A code printed on a label has to answer for the whole life of the garment. An address built on an internal product id will not survive a shop rebuild.
4. Print a code that points at you. A QR is enough, and it reads with any phone camera, with no app to install.
5. Buy nothing yet. Not identifiers, not a traceability platform subscription. The regulation mandates no vendor, and the sector requirements are not written.

Making a first passport

DPTag puts those five moves inside WooCommerce. The free plugin creates passports from the product screen, pre-fills them from your attributes, publishes a mobile page at a permanent address, and generates the QR code. There is no cap on how many passports you publish.

Once the plugin is active, the wizard walks you through the store defaults, then composition per category, then creates the catalogue's passports in batches. On an ordinary clothing catalogue the first passport takes a few minutes, and the rest only ask you about the exceptions.