Validate Open Data Contract Standard contracts instantly. Paste YAML or JSON below.
v3.1.0v3.0.2v3.0.0v2.2.2
Your Contract
Validation Results
Paste an ODCS contract on the left to see validation results here.
Supported ODCS versions
The validator automatically picks the correct schema based on the apiVersion field in your contract. If the version is unrecognised, validation falls back to the latest schema (v3.1.0).
| apiVersion | Status | Notable changes |
|---|---|---|
| v3.1.0 | Latest | Strict schema, FK relationships, improved library metrics, deprecated fields removed |
| v3.0.2 | Supported | Also has a strict schema variant; backward-compatible with v3.1.0 contracts |
| v3.0.1 | Supported | Validated against v3.0.2 schema (closest match) |
| v3.0.0 | Supported | Major v3 rewrite — objects/properties terminology, complex data structures |
| v2.2.2 / v2.2.1 / v2.2.0 | Legacy | Pre-v3 format, table/column model; validated against v2.2.2 schema |
Frequently asked questions
What is the Open Data Contract Standard (ODCS)?
ODCS is an open specification (Apache 2.0 license) maintained by the Bitol / LF AI & Data Foundation. It defines a machine-readable YAML or JSON format for formalising the agreement between data producers and consumers — covering schema, quality rules, SLA, team ownership, IAM roles, pricing, and server infrastructure.
What ODCS versions does this validator support?
v3.1.0 (latest), v3.0.2, v3.0.1, v3.0.0, and v2.2.2/v2.2.1/v2.2.0 (legacy). The validator reads the apiVersion field from your contract and automatically selects the matching bundled JSON Schema.
Why does my contract fail with "additional properties" errors?
ODCS v3.1.0 introduced strict JSON Schema validation — additionalProperties: false at the root level and most nested objects. Any field not defined in the standard will be rejected. Move custom fields into a customProperties array. For example: customProperties: [{property: myField, value: myValue}].
Can I use JSON instead of YAML for my ODCS contract?
Yes — ODCS supports both formats equally. The validator auto-detects JSON or YAML. JSON is useful for programmatic generation or API transport; YAML is the more popular choice for human-authored contracts.
Is my contract data sent to a server?
No. All validation runs entirely in your browser. The ODCS JSON Schemas are bundled with the page. Your contract text never leaves your machine and no data is stored or logged.
The validator shows a version warning. What does that mean?
If your contract's apiVersion is not in the supported list (or is missing), the validator falls back to the latest schema (v3.1.0) and shows a soft warning. Your contract is still validated — the warning just informs you that an exact schema match was not found.
What is the difference between apiVersion and version in ODCS?
apiVersion is the ODCS standard version — it identifies which version of the specification your contract follows (e.g. v3.1.0). version is the contract's own semver version, tracking how the contract itself has changed over time (e.g. 1.3.0). They are completely independent fields.
Where can I learn more about writing ODCS contracts?
The official documentation is at https://bitol-io.github.io/open-data-contract-standard/v3.1.0/. The specification is split into sections for Fundamentals, Schema, References, Data Quality, SLA, Servers, Team, Roles, Support, Pricing, and Custom Properties. The GitHub repository at https://github.com/bitol-io/open-data-contract-standard also has many example contracts.