The machine-readable Digital Product Passport: what the ESPR requires, and why AI agents will read it

TL;DR

• A machine-readable Digital Product Passport is a legal requirement: the ESPR says passport data must be based on open standards, interoperable, and as appropriate machine-readable, structured, searchable and transferable without vendor lock-in.
• A web page a person can read is not enough on its own. Software has to be able to request the same data in a structured format, with every field labelled and every product named by a persistent identifier.
• The data the law requires to be accurate, complete and up to date is the same data an AI agent needs to know exactly which product it is looking at, provided it respects the access rights the passport sets.

A machine-readable Digital Product Passport is one that software can read as reliably as a person can. That is not a nice-to-have. The ESPR, Regulation (EU) 2024/1781, writes it into the essential requirements every passport has to meet, and the European standards cited in July 2026 turn those requirements into something buildable.

This guide covers what the Regulation says, how a human-readable passport page differs from a machine-readable one, the building blocks in common use, and why the same data is becoming a trusted source for AI agents. The list of data a passport must carry is covered separately in Digital Product Passport data requirements. Everything below is stated as of October 2026.

What does the ESPR say about machine-readability?

Article 10(1)(d) sets the rules for the data itself. All passport data must be:

• based on open standards
• developed with an interoperable format
• as appropriate, machine-readable, structured and searchable
• transferable through an open interoperable data exchange network without vendor lock-in

Each of those words has a practical consequence.

The words "as appropriate" leave room for the delegated act for each product group to decide how far each requirement goes. They do not make machine-readability optional.

Article 11 adds the system-level rules. Point (a) requires each passport to be fully interoperable with the other passports required under the ESPR "in relation to the technical, semantic and organisational aspects of end-to-end communication and data transfer". Technical interoperability means systems can exchange data. Semantic interoperability means they agree on what the data means: that "recycled content" in one passport is the same thing, measured the same way, as in another.

Article 11 also requires data authentication, reliability and integrity (point (g)), and Article 9(1) requires passport data to be accurate, complete and up to date.

The milestones so far

Human-readable versus machine-readable: what is the difference?

Picture the same kettle passport delivered two ways.

The human-readable version is a web page. A consumer scans the QR code on the box and sees the materials, repair instructions, spare parts and recycling guidance, laid out for a phone. It is the right experience for a person. A program reading that page has to guess which number is the wattage and which is the cable length, and the guess breaks whenever the design changes.

The machine-readable version is the same facts expressed as data. Each value has a name, a defined meaning and, where relevant, a unit, and the product is named by a persistent identifier. A recycler's system or a marketplace gets the same answer every time, whatever the page looks like.

A well-built passport does both from one record, so the page and the data cannot drift apart.

What a machine-readable record can look like

Here is a deliberately small illustrative example in JSON-LD, the W3C format for linked data in JSON. It is not taken from any standard or delegated act, and a real passport would carry far more data. It uses terms from the GS1 Web Vocabulary and GS1's own example GTIN.

{
  "@context": { "gs1": "https://ref.gs1.org/voc/" },
  "@id": "https://example.com/01/09520123456788",
  "@type": "gs1:Product",
  "gs1:gtin": "09520123456788",
  "gs1:productName": { "@value": "Example kettle 1.7 l", "@language": "en" },
  "gs1:dpp": { "@id": "https://example.com/passport/01/09520123456788" }
}

The @id is a web address built from the product's identifier, so the record names one exact product. Every property points to a published definition anyone can look up. And the passport link is typed: gs1:dpp tells software that it leads to the Digital Product Passport.

What do the CEN and CENELEC standards cover?

The ESPR states the requirements. The European standards say how to meet them. Six core standards, developed by the joint committee CEN/CLC/JTC 24 at the Commission's request, were cited as harmonised standards by Implementing Decision (EU) 2026/1736, published on 15 July 2026. Under Article 41(2) of the ESPR, a passport that conforms to them is presumed to conform to the requirements of Articles 10 and 11 that they cover.

EN 18222 is the standard whose title names searchability, and EN 18223 addresses the interoperability Article 11(a) demands. CEN and CENELEC describe the series as eight standards. The remaining two, EN 18239 on access rights management, security and business confidentiality and EN 18246 on data authentication, reliability and integrity, were published on 16 September 2026 and, as of October 2026, have not yet been cited in the Official Journal.

The standards define how a passport works, not which data a product group has to carry. We cover each one in the six CEN DPP standards explained; the texts themselves are sold through national standards bodies, so we do not reproduce their technical content.

What are the common technical building blocks?

A machine-readable passport is assembled from a few open building blocks. The exact choices will follow the harmonised standards and each delegated act; what follows is the common web toolkit they draw on.

A persistent identifier, expressed as a web address

Article 10(1)(a) requires the passport to be connected through a data carrier to a persistent unique product identifier, and Annex III names the ISO/IEC 15459 series for the carrier and identifiers. The GTIN is built on that family. GS1 Digital Link, whose URI Syntax standard reached release 1.7.0 in August 2026, turns the GTIN into a web address, with optional batch or serial number for batch-level and item-level passports. The same address works as a QR code on the pack and as the @id of the product in structured data, which is why one code can serve both the shopper and the software.

JSON and JSON-LD

JSON is the everyday format of web APIs. JSON-LD, a W3C Recommendation, adds a @context that maps each field to a published vocabulary, such as the GS1 Web Vocabulary or schema.org, which search engines use and which also has a gtin property. Two systems using the same vocabulary understand each other without a bilateral agreement, which is semantic interoperability in its most common web form.

A resolver and typed links

A resolver is the service behind a GS1 Digital Link URI that decides where a scan or a request goes. The GS1-Conformant Resolver Standard, release 1.2.1 ratified in August 2026, lets one identifier offer many links, each labelled with a link type from the GS1 Web Vocabulary. GS1 has defined a link type specifically for passports, gs1:dpp, described as "a link to a digital product passport", alongside related types such as gs1:sustainabilityInfo, gs1:instructions, gs1:safetyInfo, gs1:certificationInfo and gs1:recallStatus.

Under the resolver standard, software can ask for one link type with a linkType parameter, or for the full linkset (IETF RFC 9264) as JSON by sending Accept: application/linkset+json. A phone scanning the code lands on the consumer page, while a program querying the same address discovers where the passport data lives. Our guide to the GS1 Digital Link resolver explains the mechanics.

Where the QR code genuinely helps is the physical step: it carries the identifier from the product into the digital world. It does not make the data machine-readable by itself. A QR code that leads to a PDF meets the data carrier requirement and fails Article 10(1)(d).

Why does a machine-readable passport matter to AI agents?

AI agents are starting to search, compare and buy on behalf of people and businesses. At the W3C/GS1 workshop in Zurich, Digital Link's CEO Paula Rivero described the failure that follows when they cannot pin down identity: an agent can complete every step of a purchase and still buy the wrong product, because a description matches several items and only an identifier names one.

What follows is our reading of how the pieces fit, not something any law or agent protocol states: the ESPR does not mention AI agents. But the qualities it demands are the ones an agent needs.

• An exact identity. The passport is anchored to a persistent identifier, so an agent comparing two near-identical products can tell them apart by GTIN, batch or serial number, not by name.
• Data with defined meaning. Structured fields from a shared vocabulary can be read without scraping a retailer page and inferring the specification.
• A legal duty of accuracy. Article 9(1) requires passport data to be accurate, complete and up to date, and Article 11(g) requires authentication, reliability and integrity. Few other sources of product data carry those obligations.
• Provenance. Only the actors the delegated act names may create or update the passport, so an agent knows whose statement it is reading.
• Reach into online sales. Article 9(2)(e) lets the delegated act set how customers see the passport before they buy, including in distance selling, and Article 10(3) obliges the economic operator to give dealers and online marketplaces a digital copy of the data carrier or identifier on request.

When a shopper asks an agent for "a kettle with replaceable parts and at least 50% recycled plastic", a passport that exposes those facts as structured, authoritative data is a better source than a guess assembled from reviews.

Access rights still apply

None of this means an agent sees everything. Article 11(b) gives each actor access according to the rights set in the delegated act, and Article 11(f) restricts who can write. A shopping agent acting for a consumer reads, at most, what the consumer could read: the public part. Data reserved for repairers, recyclers or authorities stays reserved, and the passport system has to enforce that. Our guide to Digital Product Passport access rights explains who sees what, and how confidential business information stays protected.

The boundary runs the other way too: under Article 10(1)(e), customers' personal data cannot be stored in the passport without their explicit consent.

What to do now

1. Fix your identifiers. Make sure every product has a GTIN or equivalent, and decide whether your products may need batch-level or item-level passports.
2. Use a GS1 Digital Link QR code as the data carrier, so the same code works for shoppers, inspectors and software.
3. Model your data once, in a structured form. Map each attribute you hold to a published vocabulary term before you design any page.
4. Serve both views from the same record: a page for people, structured data for software, with typed links so programs can find the passport.
5. Plan the access tiers early. Decide which data is public and which is restricted, and check that your platform enforces it for every kind of requester.
6. Ask your provider about the harmonised standards. Check how its exchange, API and interoperability features relate to EN 18216 to EN 18223, and how you could move your data out.
7. Treat public passport data as your most authoritative product feed. Once it is structured and accurate, the same data can serve marketplaces, search engines and AI agents.

Digital Link is a GS1 solution partner, and our platform builds standards-based product passports on a persistent identifier per product, with a GS1 Digital Link QR code as the data carrier and a resolver that serves people and software from the same record, with public and restricted data kept separate. If you want to check whether your product data is ready to be read by machines as well as people, get in touch and our team will review your case.

Frequently asked questions

Does the ESPR require a Digital Product Passport to be machine-readable?

Yes. Article 10(1)(d) requires all passport data to be based on open standards, in an interoperable format, and, as appropriate, machine-readable, structured, searchable and transferable without vendor lock-in.

Is a PDF a machine-readable Digital Product Passport?

No. A PDF, such as a declaration of conformity, can be linked from a passport, but the passport data itself has to be structured so software can read and search it.

Does the ESPR require JSON-LD?

No. The Regulation sets the qualities the data must have and does not name a format. JSON-LD is a widely used open W3C format that meets those qualities well, and the formats used in practice will follow the harmonised standards and the delegated acts.

Which standards cover DPP data exchange and interoperability?

The harmonised standards cited in July 2026 by Implementing Decision (EU) 2026/1736 include EN 18216 on data exchange protocols, EN 18222 on APIs for lifecycle management and searchability, and EN 18223 on system interoperability. Conforming to them gives a presumption of conformity with the ESPR requirements they cover.

Is there a GS1 Digital Link link type for the Digital Product Passport?

Yes. The GS1 Web Vocabulary defines gs1:dpp, described as a link to a digital product passport. A resolver can use it to label the passport link, so software can find the passport from the product's identifier.

Can AI agents read Digital Product Passport data?

They can read whatever their user is entitled to read, which for a consumer means the public part of the passport. Restricted data stays restricted under the access rights set in each delegated act. The ESPR does not mention AI agents; that structured passport data suits them is our reading of the requirements.