DPP Schema Validator API
Paste or send product JSON to receive deterministic missing-field, type, and formatting errors with a machine-readable response.
No account required for the . Results stay in your browser.
POST-compatible contract
POST /validate
Content-Type: application/json
{ product payload }Why validate Digital Product Passport JSON
A passport can look correct to a human and still fail downstream systems because fields are missing, data types are inconsistent, identifiers use the wrong format or percentages do not reconcile. Validation catches predictable structural errors before data reaches a registry, service provider, customer interface or trading partner.
ESPR requires passport data to be accurate, complete and up to date, and describes interoperable, machine-readable, structured, searchable and transferable data. Product-specific measures will determine the exact mandatory content and access rights. This validator is therefore a starter quality check rather than a universal legal schema.
Current validation contract
| Path | Rule | Example |
|---|---|---|
| productId | Required string | SKU-1001 |
| name | Required string | Organic Cotton T-Shirt |
| category | Required string | textiles |
| manufacturer.name | Required string | Example Brand |
| countryOfOrigin | Required two-letter uppercase code | PK |
| materials | Non-empty array | [{"name":"Cotton","percentage":100}] |
| materials[].percentage | Number from 0 to 100 | 80 |
| Material total | Percentages must total 100 | 80 + 20 |
Example errors
Missing identity
A product without a stable identifier is difficult to connect to a data carrier, evidence package, version history or downstream record.
Invalid country code
Free-text country names create inconsistent integrations. The starter rule expects an ISO-style two-letter uppercase code.
Material mismatch
Percentages that total 95 or 110 indicate incomplete composition, duplicate components or inconsistent units.
Wrong data type
A numeric value stored as text can break calculations and schema validation even when it appears visually correct.
Production schema considerations
- Define stable product, operator and facility identifiers.
- Separate model-, batch- and item-level data.
- Represent units explicitly instead of embedding them in free text.
- Track data provenance, evidence references, timestamps and version history.
- Define public, restricted and authority-only access classes.
- Validate enumerations, code lists, languages and date formats.
- Document backward compatibility and migration rules.
- Avoid storing customer personal data unless a lawful and explicit basis exists.
How to use the downloadable OpenAPI file
The generated OpenAPI document can be used as a starting artifact for discussion with developers. Before production use, add complete request and response schemas, authentication, rate limits, error codes, examples, versioning, logging, privacy controls and product-category requirements.
Frequently asked questions
Is there one universal official DPP JSON schema?
No. Product-specific measures determine required data, while implementations must support appropriate interoperable formats and access rules.
What does this validator check?
It checks required identity fields, manufacturer name, country-code format, material structure, percentage ranges and the composition total.
Does PASS mean regulatory compliance?
No. It only means the JSON satisfies this tool’s implemented checks.
Is the displayed POST endpoint live?
No. The public page validates in the browser. The OpenAPI download is a starter contract.
Official source
Regulation (EU) 2024/1781, Articles 9–11 and Annex III
Schema guidance last reviewed: July 25, 2026.