Skip to content
Knowledge / Implementation & Decisions

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.

Last verified
Share
LinkedIn X Email
Navigate this page

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:

QuestionWhat 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.

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:

FactScope
Fibre compositionProduct / variant
Model identifierProduct / model
EU Registry registration identifierRegistered DPP
French safety wordingFrance / French presentation
German safety wordingGermany / German presentation
EPR producer registrationMarket / scheme
Customer-facing product nameLanguage / 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?.

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.

Activate one product →

Keep exploring

The questions this page usually raises next.

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.

Worth sharing?

Help someone else make sense of product passports.

LinkedInXEmail

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.