A useful Digital Product Passport example is not one long public webpage. It connects a persistent product identifier to structured data and delivers different information to consumers, repairers, business partners and authorities. The examples below are illustrative — product-specific EU law determines the mandatory fields, granularity, access rights and application date.
Example 1: consumer product view
A consumer scans a carrier and sees a mobile page with the product name and model, manufacturer, material composition, care and repair guidance, durability information, relevant environmental indicators and end-of-life routes.
The page prioritises plain language and accessible evidence. Restricted supplier contracts, detailed conformity files and commercially sensitive facility data are not exposed.
| Section | Illustrative content |
|---|---|
| Identity | Product name, model, unique identifier, responsible operator |
| Composition | Main materials and declared recycled content |
| Use and care | Instructions that support durability and safe use |
| Repair | Spare-part, disassembly or authorised repair information |
| End of life | Collection, reuse and recycling guidance |
| Evidence | Links or references supporting regulated claims |
Example 2: repairer view
After authentication, an authorised repairer could receive the same public information plus diagnostic guidance, compatible parts, disassembly instructions and safety constraints. The system records the access role and returns only the fields that role may use.
This illustrates why access control belongs in the data architecture. It cannot be solved by producing one static PDF for everyone.
Example 3: authority view
A market-surveillance or customs user may need identifiers, economic-operator information, applicable conformity documents and other restricted evidence. The DPP should let the authorised user locate the current record without making those documents publicly discoverable.
Example structured record
An implementation may expose machine-readable data alongside the human view. A simplified record could contain:
{
"productId": "https://id.example.com/01/09506000134352",
"passportVersion": "1.2",
"product": {
"name": "Illustrative Work Jacket",
"model": "WJ-100"
},
"responsibleOperator": {
"name": "Example Manufacturer EU"
},
"materials": [
{ "name": "Cotton", "sharePercent": 70 },
{ "name": "Recycled polyester", "sharePercent": 30 }
],
"lastUpdated": "2026-09-09"
}
Real records need defined vocabularies, evidence, identifiers, access policy and every field mandated for the product. JSON alone does not make a passport interoperable.
Example QR and resolver journey
- A manufacturer assigns the product identifier.
- The identifier is encoded in a standards-compatible web address.
- A QR code carrying that address is applied in the required location.
- A resolver receives the scan and identifies available resources.
- The user receives a consumer view, while authorised roles can request restricted resources.
- The identifier continues to work when a page layout or backend changes.
Battery passport example
The EU Battery Regulation offers the most concrete statutory example. Annex XIII groups information around the battery and manufacturer, conformity and labels, carbon footprint, supply-chain due diligence, material composition, circularity, performance and durability. Access is not identical for every field or user.
See the battery passport guide for scope and the 18 February 2027 date.
What a good example should prove
A credible proof of concept should demonstrate traceability to source evidence, role-based access, a correction, a product revision, carrier resolution, machine-readable export, registry workflow and continuity if the publishing service changes.
A beautiful public page proves only the presentation layer.
Frequently asked questions
Is there one official DPP template?
No single visual template applies to every product. Product-specific rules define required data and access, while companies can design user views around those constraints.
Can one passport have different views?
Yes. The same product identity can resolve to information appropriate for consumers, repairers, supply-chain partners and authorities, with access controls for restricted fields.
Are the examples on this page legally compliant templates?
No. They are illustrative records showing structure and user journeys. Compliance must be validated against the adopted legislation for the specific product.