A Digital Product Passport QR code is a data carrier: it can encode a product identifier or identifying URL that leads to passport information. The printed symbol is not the passport or the service that retrieves it. Start by establishing the applicable product rules, identifier scope and access requirements, then check the destination and who will maintain it.
Is a QR code legally required for a DPP?
Answer checked:
Not for every DPP under one universal rule. ESPR requires a data carrier connected to a persistent unique product identifier, while the applicable product-specific act determines the carrier type and placement. A QR code is one possible carrier.
Batteries have a specific rule: from 18 February 2027, Article 13(6) requires QR marking for batteries within its scope. For EV, LMT and industrial batteries greater than 2 kWh, it links to the battery passport; for other battery categories it links to the information specified there. A QR requirement therefore does not always mean a passport requirement.
Battery marking must be visible, legible and indelible. Where the nature or size of the battery makes on-battery marking impossible or unwarranted, Article 13(7) places it on the packaging and accompanying documents. Check the Regulation’s exclusions, the applicable product act and the destination before printing.
Source: ESPR — Regulation (EU) 2024/1781 — Articles 2, 4, 9–13 and 27–38; current displayed consolidation. As checked 22 September 2026.
Source: Battery Regulation — current consolidated text — Consolidation 13 August 2026; Articles 1, 3, 13, 39, 77–78 and Annex XIII. As checked 22 September 2026.
Does every product need a unique QR code?
Answer checked:
No. ESPR allows passport information at model, batch or item level, as specified by the applicable product rules. A unique product identifier does not automatically mean a different code for every physical unit.
If the required granularity is model or batch level, a shared carrier can identify that model or batch where the rules permit it. If item-level identification is required, the identifier and its destination must distinguish the individual item; repeating one generic product-page QR is insufficient.
Battery passports are a specific individual-battery case: Article 77 requires a QR-linked unique identifier and model plus individual-battery information. Do not generalise that rule to all ESPR products. Decide the legally required granularity before designing labels or purchasing serial numbers.
Source: ESPR — Regulation (EU) 2024/1781 — Articles 2, 4, 9–13 and 27–38; current displayed consolidation. As checked 22 September 2026.
Source: Battery Regulation — current consolidated text — Consolidation 13 August 2026; Articles 1, 3, 13, 39, 77–78 and Annex XIII. As checked 22 September 2026.
What a DPP QR code does
Illustrative URL-based flow: QR carrier → identifying URL → retrieval service → controlled record. A browser may follow a redirect or receive a page directly. A resolver service can associate an identifier with different resources; the QR symbol itself does not perform that work. The four stages below describe an architecture, not a universal requirement to use a resolver.
Legal framework: ESPR Article 10(1)(a) connects the passport through a data carrier to a persistent unique product identifier. Article 9(2)(b)–(c) assigns the carrier and its placement to the applicable delegated act. These provisions do not establish that every product must use a QR code. Check the relevant product measure before selecting a carrier. Sources reviewed 20 September 2026.
A resolving code, the passport data service and the EU Registry perform different functions.
- Follow the wider passport preparation sequence
- Separate passport hosting from EU Registry registration
Printed QR symbol
The scanner reads the encoded characters from the physical label.
Which product scope?
The identifying URL refers to the intended model, batch or item; it is not the entire record.
Reach the resource
The service returns the resource directly or resolves and redirects the request, according to the chosen design.
Read permitted information
The maintained record and its access controls determine what the reader can obtain.
Decide what the identifier identifies
Legal framework: ESPR Article 9(2)(d) and Article 10(1)(f) provide for model, batch or item level as specified in the applicable delegated act. A commercial SKU or product family is not automatically the legally required identifier scope. Record the rule and its source before deciding which products share a code.
Use this decision table in your own controlled record. The suggested owners are operational roles, not a transfer of legal responsibility. For the selected level, record the actual identifier scheme, rule citation, evidence owner and unresolved question. Leave the decision unresolved where the applicable measure has not been established.
- Battery QR code and unique-identifier requirements
- Resolve data requirements before choosing what the carrier exposes
| Possible level | Rule and evidence to record | Suggested owner / unresolved decision |
|---|---|---|
| Model | Cite the applicable level requirement; define the model and which variants it includes. | Product and regulatory leads: does the selected model boundary match the rule? |
| Batch | Cite the level requirement; retain the lot definition and evidence linking units to that lot. | Quality and operations: what change starts a new batch? |
| Item | Cite the level requirement; retain the unique item identity and its link to the physical unit. | Traceability and regulatory leads: how are replacements and duplicate labels controlled? |
What goes inside the QR code
Architecture recommendation: for a web-accessible design, encode a stable HTTPS identifying URL rather than a large dataset that will change after printing. Separate the identity from the current storage location. Decide who controls the identifying domain and how that control survives a provider change. A first-party domain can support that control, but these ESPR provisions do not universally require one.
Illustrative text only: https://example.com/products/model-a/batches/batch-b represents a fictional batch-identifying URL. The path is deliberately generic; it is not a GS1 Digital Link example, an allocated identifier or an operating passport. No live passport is provided here. Its record could receive a corrected instruction while the batch identity remains the same; a different physical batch must not silently inherit that identity.
Keep passwords, access tokens, private documents and personal information out of the printed URL. Treat an encoded identifier as public even when its destination includes restricted data. Non-sequential identifiers may be an architecture choice, but obscurity is not access control. Enforce permissions at the resource and avoid exposing draft or private information in the public response.
Separate GS1 Digital Link syntax from resolver behaviour
Technical standards: GS1 Digital Link URI Syntax 1.7.0 (August 2026), section 2, explicitly separates URI syntax conformance from resolver behaviour. Sections 3.1, 4.3–4.4 and 5 describe identifiers, their structure and examples. A standards-based URL must use the appropriate identifier scheme and syntax; adding a product number to an arbitrary URL does not establish conformance.
GS1-Conformant Resolver 1.2.1 (August 2026) is a separate standard for resolution. Section 1.1 permits Digital Link URIs without a GS1-conformant resolver and recommends, rather than universally requires, redirection. If claiming resolver conformance, review the service against that standard as well as reviewing the URI. A page that loads successfully is not, by itself, evidence of resolver conformance. The normative editions are linked under Primary sources; reviewed 20 September 2026.
Legal applicability is a separate question. ESPR Article 10(1)(c) addresses carrier and identifier standards and Article 9(2) specifies matters for product measures. This guide does not establish a universal GS1-only requirement or the current harmonised-standard publication status. A valid URI, conformant resolver or successful scan does not verify the passport data or determine that a product complies.
| Layer | Evidence to ask for | What it does not establish |
|---|---|---|
| Identifier | Scheme, allocation authority where relevant, uniqueness and model/batch/item scope. | Correct destination or data. |
| URI syntax | Validation against the identified normative edition and its relevant rules. | Resolver-service conformance. |
| Resolver service | Tests and documentation against the resolver standard being claimed. | Truth of the information retrieved. |
| Product obligation | Applicable measure, dates, actor role, required carrier, data and access rules. | Compliance merely because the technical checks above pass. |
Check the destination before printing
This is a static operational checklist to copy into your own review record. It does not save answers, generate codes, validate documents or score compliance. For every row, assign a named owner, link the dated evidence, and record Open, Evidenced or Not applicable with a reason. Evidenced means the operational check has supporting material; it is not a legal approval.
Keep unresolved questions visible before committing to a print run. Use applicable carrier and print specifications plus tests on the intended product or packaging, substrate, placement and scanning conditions. This guide sets no universal code size, contrast value, quiet-zone dimension or scan-distance threshold.
| Check / suggested owner | Evidence to retain | Unresolved state to record |
|---|---|---|
| Applicable scope — regulatory lead | Product measure, actor role, applicability date, carrier and identifier-level decision. | Open until the applicable basis and remaining questions are recorded. |
| Identifier uniqueness — traceability lead | Allocation record and a check for duplicate or reused identities within the relevant scheme. | Open if two products can unintentionally receive the same identity. |
| Expected destination — publishing owner | Decoded URL, redirect path if any, final resource and a match to the intended model, batch or item. | Open if the code reaches a draft, wrong product, generic homepage or error. |
| Access separation — security and data owners | Public response plus permitted and unauthorised access checks for restricted information. | Open if private data or an access token is exposed, or required readers cannot obtain access. |
| Update control — data owner | Approval record, version history and a tested update that preserves the intended identity. | Open if an update silently changes product scope or cannot be traced to an approver. |
| Identifier retention — service owner | Domain and provider responsibilities, required availability period and migration plan. | Open if renewal, provider exit or identifier reassignment could break the link. |
| Failure and retirement — operations owner | Documented responses for unavailable, retired or replaced records and an escalation contact. | Open if a missing record resolves to another product or appears valid without explanation. |
| Physical scan — packaging and quality owners | Dated samples tested under intended use conditions, devices and relevant print specifications. | Open if a successful screen scan is the only evidence for the printed material. |
Plan changes without losing the identifier
Assign these responsibilities before selecting a service. They are operational recommendations. Separately establish the legally required availability period, access rights and update roles from the applicable measure: ESPR Article 9(2)(f)–(i), Article 10(1)(g) and Article 11(b), (e)–(f) provide the relevant framework. A provider contract does not itself determine those duties.
A durable identifier needs a maintained retrieval path. Plan a domain or provider transition before retiring the old service; test existing printed codes against the new destination and preserve the link to the same product scope. Exported files alone do not keep a printed URL working.
| Responsibility | Suggested accountable owner | Handover evidence |
|---|---|---|
| Domain and resolution control | Service owner with a named deputy | Renewal responsibility, access recovery, routing inventory and failure escalation. |
| Record changes | Product data owner and approver | Version history, approval rules and evidence that the product identity is retained. |
| Provider exit and migration | Procurement with technical operations | Export scope, identifier mapping, transfer responsibilities and tests of previously printed codes. |
| Retired, recalled or replaced records | Product and regulatory leads with operations | Required retention decision, explicit record state and any replacement relationship; no silent reuse for a different product. |
What passing these checks cannot establish
DPPLogic provides this guide for preparation. This page does not issue identifiers, generate QR codes, host passports or connect a product to the DPP Registry. Use the existing applicability, data and software guidance for the decisions that sit outside a carrier review.
- Check the product and role applicability questions
- Prepare the required data and supporting evidence
- Compare software and procurement evidence
- It does not determine whether a product is legally in scope or which product measure applies.
- It does not validate the underlying data or evidence against applicable requirements.
- It does not prove conformance to an identifier or resolver standard that has not been tested.
- It does not make private documents safe to publish or replace access controls.
- It does not establish DPP Registry acceptance, certification or regulatory approval.
Work through model, batch and item identifiers
Use a fictional identifier crosswalk to see how a product change affects record scope and evidence references. Internal identifiers in the example are teaching values, not registered passport identifiers.
Primary and authoritative sources
Source links are provided for verification. Scope, consolidated versions and later measures should be checked again before implementation or reliance.
Regulatory disclaimer. This content provides general diagnostic and preparation information. It is not legal advice, certification or regulatory approval. Requirements may differ by product category, jurisdiction, market and supply-chain role and may change over time.