Digital Product Passport: Example, Template and JSON Explained

This page explores one part of the Digital Product Passport. For implementation, the DPP data model connects product identity, fields, evidence and access rights.

Download the versioned DPP example file

The example separates product identity, domain facts, evidence, governance and access rights. It includes version and validity fields and can support workshops or API prototypes.

Download DPP data model example v1.0 as JSON. The file is a technical illustration, not a universal compliance template. The DPP data model guide explains how to adapt it.

An example is not a form to fill in

A useful DPP example shows more than fields; it shows decisions. At which level is the product identified? Which statement comes from which system or document? Who may see what? What happens when a certificate, supplier or product version changes? Without those layers, a passport remains a pretty product page.

DPP requirements are set by product group. Therefore, no general JSON document can be “EU compliant for everything”. The European Commission DPP explainer makes precisely this product-specific point: data content and rules follow the applicable delegated or sector-specific acts.

The minimum structure of a robust pilot

A structured dataset does not automatically make a passport legally compliant. It does make review easier. The UN Transparency Protocol provides an openly documented DPP data approach, including product identity, identifier scheme and granularity. These concepts are useful for a pilot even though they do not replace an EU legal act.

What machine-readable identity can look like

The following example is intentionally shortened. It shows the separation between a resolvable product ID, model, batch and individual item. The values are fictional. Its structure is informed by the public electronics examples from OpenEPCIS, which documents smartphone, laptop, display and server passports alongside JSON-LD references.

{
  "@context": "https://example.invalid/dpp/context",
  "@type": "Product",
  "id": "https://id.example.invalid/dpp/atlas-lamp/0004711",
  "name": "Atlas Desk Lamp",
  "modelNumber": "ATLAS-LED-01",
  "batchNumber": "2026-04-DE-17",
  "itemNumber": "0004711",
  "idGranularity": "item",
  "productCategory": [{
    "code": "example-category",
    "schemeName": "illustrative classification"
  }],
  "evidence": [{
    "claim": "material composition",
    "source": "approved supplier declaration",
    "status": "illustrative only"
  }]
}

What this tells us: an identifier can refer to a model, batch or individual item, and those levels should not be silently mixed. What we must not assume: that these field names, categories or evidence structures will be prescribed for every EU product group. The legal act defines the business requirement; the data model implements it technically.

How to test a DPP example honestly

• Scan or open a real identifier and verify that it resolves to the correct version over time.
• Show at least an origin, owner and release status for every visible claim.
• Run a supplier change, expired certificate and product change as test cases.
• Test public and protected views with people from sales, quality, service and procurement.
• Promise machine-readable output only where structure and validation actually exist.

The implementation roadmap explains when this test becomes a scalable process. If the passport should use environmental information from an EPD, the comparison DPP vs. EPD explains the role an EPD can play in that data flow.

A scan test should open more than an arbitrary landing page. The guide to the Digital Product Passport QR code explains GTINs, granularity, resolvers and machine-readable targets.