in what format must I provide the product passport data

What you must concretely do

What is expected of you

The question of which file format is mandatory — JSON, XML, PDF, a specific API structure — comes up for every importer and manufacturer once the IT department starts building. The answer based on the current ESPR text is straightforward: a concrete file format is not specified in the regulation. Article 10 and Article 11 of the ESPR (Regulation (EU) 2024/1781) do establish what the digital product passport must meet, but this is done at the level of functional and technical requirements, not at the level of "use JSON-LD" or "submit an XML file according to this schema". That implementation is expected via delegated and implementing acts, per product group.

Interoperability is the focus, not one specific format

Article 10 of the ESPR mentions interoperability as a core requirement: the passport must be structured so that systems of different parties — supervisory authorities, market participants, consumers — can read the data. For a company with 10 to 100 employees, this practically means that the choice for a storage and exchange format can only be made with certainty once the delegated act for your own product category is available. Until then, it is advisable to work with structured data (think of fields in a database or ERP system) rather than keeping data only in a loose document or PDF, so that a later disclosure in the ultimate format requires less rework.

The passport must be readable via the QR data carrier

Article 11 of the ESPR describes the technical functioning of the passport, including the link with the data carrier on the product. This means that the underlying data, in whatever format, must be able to be retrieved at the moment someone scans the code. How that link works technically and which identification standards play a role in it is described on the page about how does the QR code for the product passport get onto my electronics. For companies already working with GS1 barcodes, the question of whether an existing identification structure can be reused is relevant — that subject returns on the page about what GS1 Digital Link is and whether it is necessary for the product passport.

Each product must be uniquely identifiable, regardless of the file format

Regardless of which technical format will eventually be prescribed, the underlying requirement is that each product receives a unique identification code. This is a separate requirement that does not change if the file format is determined later. Companies that start structuring their product data now would be well advised to include this identification as a permanent part of it. How this is built in practice is explained on the page about how you assign each product a unique identification code.

Submission to the register requires its own form

Article 13 of the ESPR introduces the register of digital product passports, in which certain data about the passport is recorded. Here too, it has not yet been determined in which exact file format that submission must take place — that will be determined later. It is clear, however, that this register is a separate submission stream alongside the passport that is accessible via the QR code. More about what must be included in it is on the page about what the register of digital product passports is and what must be included in it.

Where things go wrong in practice

Locking in too early to a rigid format. Some companies are already having a PDF passport built because it is quick and recognizable, while the ultimate requirement will probably require structured, machine-readable data. A PDF is readable by humans, but not automatically suitable for the interoperability that Article 10 of the ESPR aims for.

Data scattered across multiple systems without linking. Product information is often partly in the ERP system, partly in marketing documents, partly with an external supplier. Without a plan to bring this together, it will be difficult to switch quickly later once the mandatory format is known. Companies considering having their own system participate will find more about the options on the page about linking the product passport to your own ERP or inventory system.

Confusion between the passport itself and the register. The passport that can be consulted via the QR code and the data that goes into the register are not automatically identical in form or format. Assuming that one file will suffice for both purposes is a risk that only becomes visible once the implementing acts become concrete.

Not accounting for multiple product levels. For products sold in composite packaging, or where a device consists of multiple parts each with their own passport, the question of how the data formats fit together is even more complex. This applies for example to a box containing multiple devices and for products that require multiple product passports.

Insufficient attention to long-term readability. A file format that is current now does not have to remain so over a longer period. Because the passport must remain accessible for a certain period, the choice of format is also a question about durability — see the explanation about how long a product passport must remain available.

What you can document

• An overview of where product data is currently recorded (ERP, PIM, spreadsheets, supplier documents) and in what format.
• A list of mandatory data sources per product category, once the delegated act for that category has been published.
• Agreements with suppliers and sub-suppliers on the format in which they supply their product data, so that alignment is easier later.
• An internal responsible person or team that follows the development of the technical standards, since Article 11 of the ESPR will receive further specifications on this.
• Documentation of the chosen identification method per product, also separate from the ultimate file format.
• An overview of the requirements for hosting and availability, which together with the format determine how the passport is technically set up — see the page about which hosting requirements apply.