Developer · Validator

OpenAPI validator.

Paste an OpenAPI 3.0 or 3.1 document, as JSON or YAML, and check it against the official OpenAPI Initiative schema. Each problem is reported with its path in the document. Runs in your browser; nothing is uploaded.

Advertisement

Input

JSON or YAML. The version is read from the openapi field.

Result

Paste an OpenAPI document and press Validate.

How the OpenAPI check works

The text is parsed as JSON if it starts with {, otherwise as YAML with js-yaml 4.1.1. The openapi field picks the schema: 3.0.x uses the official OpenAPI 3.0 schema dated 2024-10-18, and 3.1.x uses the official OpenAPI 3.1 schema dated 2022-10-07 together with the OAS 3.1 Schema Object dialect, so the JSON Schemas inside components, parameters and bodies are checked as well. Ajv 8.17.1 runs the schema in your browser and lists every failure with its location, written as a path such as paths['/pets'].get.responses.

Worked example. The built-in example is a 3.0.3 document whose info block has no version, whose path parameter id is missing required: true, and whose responses uses the key abc. Those are reported as three separate errors with their paths; fixing them makes the document valid.

Error reading. A schema check for OpenAPI involves many one of alternatives (for example a parameter can be a Reference Object or one of four parameter kinds), so Ajv reports every alternative that failed. This tool hides the alternatives that are clearly not the intended one, but on an unusual mistake the message can still point at a neighbouring property. Read the path first.

What the schema does not cover. The official schema checks structure. It does not check that $ref targets exist, that operationId values are unique, that every {template} in a path has a matching path parameter, or that examples match their schemas. Those rules are in the specification text but not in the schema, so a document can pass here and still be rejected by a stricter linter. OpenAPI 3.2 is not supported; Swagger 2.0 documents are recognised and reported as unsupported.

Sources (checked 30 September 2026): OpenAPI Specification (spec.openapis.org); OAS 3.0 schema, 2024-10-18; OAS 3.1 schema, 2022-10-07; OAS 3.1 Schema Object dialect; OpenAPI-Specification repository (github.com/OAI); Ajv and js-yaml, both MIT licence, vendored. The schemas are vendored with two small mechanical edits, described at the top of /js/vendor/oas-schemas.js.

Frequently asked questions

Is my API definition uploaded anywhere?

No. Parsing and validation run in your browser, and nothing you paste is stored or sent. That makes it safe for internal or unreleased specs.

Is this the same as the Swagger Editor?

No. It checks the document against the official JSON Schema and lists errors by path. It has no rendered documentation, no editor and no linting rules beyond the schema.

Why does a valid-looking spec fail?

Common causes are a missing info.version, a path parameter without required: true, a response code that is not a three-digit number, default or a pattern such as 2XX, or 3.0 keywords used in a 3.1 document (and the reverse, for example nullable).

Does it support Swagger 2.0 or OpenAPI 3.2?

No. Only 3.0.x and 3.1.x are checked. A Swagger 2.0 document is reported as unsupported rather than guessed at.

Structure check only

A pass means the document matches the structure in the official OpenAPI schema. It does not prove that the API behaves as described, that references resolve, or that a particular tool will accept the file. Nothing you type is stored or sent anywhere.

Advertisement
Advertisement
Listening…