Do I Need a Different Digital Product Passport for Every EU Country or Language?
EU DPP rules do not generally require a new passport just because the language or Member State changes. Separate product identity from multilingual market presentation.
Navigate this page
- Overview
- Direct answer
- Product identity and language are different dimensions
- The horizontal DPP rule does not say “one country, one passp
- Language is still a legal requirement
- Translate presentation, not factual truth
- One product can still differ by market
- When might you genuinely need another passport?
- What about the UK?
- Ecommerce makes the distinction visible
- Do not translate legal uncertainty into false certainty
- Direct questions
- What would change this page
- Try it on one product
- Primary and official sources
- Keep exploring
EU DPP law does not create a general rule that the same product needs a separate passport for every Member State or every language. Product identity and passport granularity are one question. Language and market presentation are another. A good system keeps them separate.
Direct answer
Usually, country and language alone are not reasons to create a new product identity or a second passport.
The horizontal DPP framework is built around product granularity such as model, batch or item. It is not built around “one passport per Member State”.
At the same time, the information supplied under ESPR has to be provided in a language customers can easily understand, as determined by the Member State where the product is made available or put into service. ESPR also requires digital instructions in an appropriate language, and the 2026 Registry regulation requires the semantic repository to contain multilingual labels and definitions for mandatory DPP attributes.
That gives businesses a cleaner architecture:
One governed product identity can support several language and market presentations, unless the applicable product rule or a real product difference requires a separate passport.
The mistake is to use translation as a reason to duplicate the product record.
The opposite mistake is to assume that one English page is automatically enough for every EU market.
Product identity and language are different dimensions
A DPP has to attach to the right product.
Under ESPR, the applicable product-specific delegated act decides whether the passport exists at:
- model level
- batch level
- item level.
That is the legal granularity question.
The same framework separately deals with language. Article 7(8) says information supplied under ESPR information requirements must be provided in a language that can be easily understood by customers, as determined by the Member State on whose market the product is made available or in which it is put into service.
Those two rules solve different problems:
| Question | What decides it? |
|---|---|
| Is this the same product passport? | Product identity and the granularity required by the applicable product rule |
| What language should the customer see? | The language requirement applicable in the destination market and the product-specific rule |
| Do some fields differ by market? | The legal or commercial rule governing that field |
| Do I need another DPP registration? | Whether the applicable law requires another product identity or registration, not translation by itself |
This is why model, variant, SKU, batch and item data should be structured before language is added on top.
The horizontal DPP rule does not say “one country, one passport”
Article 9 of ESPR requires each product-specific delegated act to choose the DPP granularity.
The choices named by the Regulation are model, batch and item.
The 2026 Registry implementing regulation follows the same architecture. Registration is made at the level specified by the applicable law, and where the same product is subject to different Union rules requiring different levels of granularity, the Registry rule says the passport is registered at the most granular level required.
There is no horizontal DPP rule in those provisions that says the same product needs a second passport merely because it is sold in France rather than Germany, or because the customer interface is French rather than German.
That does not prove that every product will always use one identical passport across the Union. A product-specific act can create additional requirements, and other Union or national rules can affect what customers must be told in a particular market.
The safer conclusion is narrower:
Do not create duplicate DPP identities merely to solve translation. Wait for a legal or product-identity reason.
For the granularity decision itself, use How many passports a range needs, and why it is not settled.
Language is still a legal requirement
The fact that language does not automatically create a new passport does not make translation optional.
ESPR Article 7(8) requires information supplied under its information requirements to be in a language customers can easily understand, as determined by the Member State concerned.
ESPR Article 27 applies the same basic language principle to digital instructions for products covered by an ESPR delegated act.
The Commission's current consumer DPP page also describes DPP information as something consumers can access in multiple languages.
And Commission Implementing Regulation (EU) 2026/1778 requires the DPP semantic repository to contain multilingual labels and definitions for all mandatory data attributes.
That last point is important technically.
The semantic repository is not just a translation dictionary. It is intended to make the meaning of DPP attributes interoperable across systems and jurisdictions.
A useful architecture is therefore:
canonical field meaning ↓ canonical product value ↓ language-specific label / explanation / presentation
rather than:
English product record French product record German product record Italian product record
with four copies that can silently diverge.
For how the EU's published definitions map into business product data, see The DPP Semantic Repository and Your Product Data.
Translate presentation, not factual truth
Some product values do not need translation at all.
Examples include:
- GTIN or another product identifier
- numeric weight
- batch number
- registration identifier
- structured country code
- machine-readable commodity code.
Other values have a language presentation layer:
- care or repair instructions
- safety statements
- customer-facing field labels
- explanatory text
- product descriptions
- disposal or recycling guidance.
And some values are controlled vocabularies that should not be translated by inventing a new free-text term in every channel. The system should preserve the canonical semantic value and display the appropriate human-readable label.
That distinction is especially useful for AI, marketplaces and machine-to-machine exchange because it lets the same underlying fact survive translation.
A field such as:
country_of_origin = PT
can be rendered as:
- Portugal
- Portugal
- Portugal
- Portogallo
without creating four different origin facts.
Likewise, a controlled material or role code can retain one semantic identity while exposing different language labels.
One product can still differ by market
There are situations where the data shown for the same commercial product may differ between Member States.
That can happen because:
- warning language differs
- instructions need translation
- producer or EPR registration information is market-specific
- the responsible economic operator shown to the customer differs under another applicable rule
- a market-specific claim is used
- packaging or local compliance information changes.
Those are reasons to support market-specific presentation or market-scoped facts.
They are not automatically reasons to mint another product identity.
A governed data model should therefore be able to represent:
global product fact
and
market-scoped fact
without confusing the two.
For example:
| Fact | Scope |
|---|---|
| Fibre composition | Product / variant |
| Model identifier | Product / model |
| EU Registry registration identifier | Registered DPP |
| French safety wording | France / French presentation |
| German safety wording | Germany / German presentation |
| EPR producer registration | Market / scheme |
| Customer-facing product name | Language / channel |
This is also why a business should not make the ecommerce storefront the only source of truth. Storefronts tend to mix product truth, marketing copy, language and market configuration into the same record.
Which System Should Own Each Product Fact? separates those roles.
When might you genuinely need another passport?
A second DPP may be needed where the underlying legal or product identity changes.
Examples can include:
A different model or sellable configuration
If the change creates a different product identity under the relevant identification rules, it may need a different passport identity.
A batch-level difference
If the applicable product rule requires batch-level DPPs, a new production batch can create another passport even if the marketing name is unchanged.
An item-level DPP
Where the rule requires item-level passports, each item can have its own passport identity regardless of market language.
The same product is caught by more than one DPP law
The 2026 Registry regulation anticipates a product being subject to more than one Union rule requiring DPP registration at different granularity levels. It says the DPP is registered at the most granular level required by the relevant Union legislation.
That is a legal-architecture question, not a translation question.
A material product change creates a new identity
A substantial product change can require a new identifier or new governed product record depending on the applicable identification rules and product law.
The operational decision is worked through in When a Product Changes, Do You Overwrite the Fact, Version the Record or Create a New Product?.
What about the UK?
The UK is not another EU Member State language presentation.
A UK business selling into the EU needs to separate:
- whether the EU product rule applies to the product being placed on the EU market
- who carries the relevant EU obligation
- what information the EU-facing product presentation needs
- what separate UK requirements apply to the same product.
That does not necessarily mean the physical product requires two unrelated product identities. It does mean the legal regimes should not be collapsed into one checklist.
The current UK boundary is covered in Whether the UK has a product passport, and what it has instead.
Ecommerce makes the distinction visible
A multilingual ecommerce business already works with this problem.
A single SKU can appear on:
example.com/fr/...example.com/de/...example.com/it/...
without becoming three different physical products.
The DPP layer should preserve the same discipline.
A customer in each market can reach the same governed passport identity and receive the appropriate language presentation where the access rules allow it.
That is cleaner than generating a separate DPP URL for each translated storefront and hoping every copy remains synchronized.
The separate question of where the DPP must be exposed during distance selling is covered in Where Does a Digital Product Passport Have to Appear on an Ecommerce Product Page?.
Do not translate legal uncertainty into false certainty
For product groups whose DPP delegated acts do not yet exist, we still do not know every language and presentation detail.
Textiles are the obvious example.
The Commission says textile-specific DPP requirements will be set through the future delegated act. It currently describes the DPP as accessible online and through the physical data carrier, but the exact information and technical presentation remain product-specific work in progress.
So for textiles, the low-regret preparation is:
- make product facts structured
- store language separately from factual identity
- retain evidence behind the canonical value
- support multilingual labels and instructions
- avoid creating country-specific DPP identities before there is a reason
- keep the presentation layer changeable.
The live regulatory status is maintained on Textile Digital Product Passport Requirements.
Direct questions
Do I need one DPP for France and another for Germany?
Not merely because the product is sold in two Member States. The horizontal DPP rules use product granularity such as model, batch or item. Language and market information still need to satisfy the applicable rules in each market.
Can one DPP page switch languages?
That is a sensible implementation pattern, provided the applicable product-specific rule, access rights and language requirements are met. The Commission's DPP consumer guidance currently describes access to product information in multiple languages.
Does every field need translating?
No. Identifiers, codes and numeric facts often remain language-neutral. Customer-facing labels, instructions, warnings and explanatory text may need language-specific presentation.
If I translate the DPP, do I need a second EU Registry registration?
Translation by itself is not identified in the horizontal Registry rules as a new registration granularity. Registration follows the product identity and level required by the applicable Union law.
Can national rules still affect what I show?
Yes. ESPR itself ties language to the Member State market, and other product, consumer, EPR or safety rules can create market-specific information requirements. Keep those facts scoped to the market rather than duplicating the entire product record.
What would change this page
Recheck this page when:
- product-specific delegated acts set detailed language or presentation rules
- the semantic repository publishes stable product-group multilingual models
- a product regime creates a country-specific registration or identity requirement
- the Commission publishes further guidance on multilingual DPP interfaces
- the law changes how multilingual instructions or customer information must be delivered.
Try it on one product
Start with one governed product record. Keep the factual value, evidence, market scope and language presentation separate before you multiply it across storefronts.
Keep exploring
The questions this page usually raises next.
- CompareNext questionHow many DPPs does one range need?→ Model, batch or item level
- Another angleNext questionWhere should model and variant facts live?→ Model vs Variant vs SKU
- CompareNext questionHow do EU semantic definitions map to my data?→ The DPP Semantic Repository and Your Product Data
- Another angleNext questionWhat is the UK position?→ UK Product Rules and the EU Passport Compared
- Another angleNext questionWhat has to appear online?→ GPSR online listing product information
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.
Help someone else make sense of product passports.
Primary and official sources
https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/textile-apparel_en Supports the current product-specific roadmap and the fact that exact textile DPP requirements remain for the future delegated act.
Last verified: 3 September 2026. This page is practical guidance, not personalised legal advice.