Lint an OpenAPI definition and local references

Paste the definition to review authoring issues. This focused linter does not provide complete schema conformance or test the behavior of a running API.

Runs locally in your browser
OpenAPI definition

Paste OpenAPI 3.0 or 3.1 JSON/YAML. The definition stays in this browser and is never fetched or uploaded.

What this checks
  • LOCAL JSON or YAML parsing, without a network request.
  • STRUCTURE OpenAPI version, info, paths, operations, and response objects.
  • REFERENCES Local #/... references and missing path parameter declarations.

This is a focused authoring linter, not a replacement for a complete schema-conformance test suite or live API contract testing.

Validation report
  • Validate an OpenAPI document to see a local report.

How to validate an OpenAPI definition

Every finding carries a severity and a JSON Pointer to the element it belongs to, so a problem can be traced back to the exact place in the definition.

  1. Paste the definition, or press Load example to start from a filled-in 3.1 document.
  2. Press Validate definition. The header counts the operations that were found, and the number of errors, warnings and notes.
  3. Read the findings list: each entry shows its level, the JSON Pointer of the affected element, and a sentence describing what is wrong.
  4. Press Clear to empty the box and the report.

What the validator checks

Problems reported as errors

A missing openapi version string, a missing info object and a missing paths object are errors, and info.title and info.version are required inside it. A path key that does not begin with / is an error, as is an operation whose responses object is empty, because consumers need at least one response code or default.

A path template such as /orders/{id} has to declare {id} with in: path and required: true, since a client cannot build a call without it. References written as #/components/... are resolved, and one that leads nowhere is reported as an error at its own pointer.

Warnings and notes

An operation without operationId is a warning, because generated clients use it as a method name. A requestBody without a content map, a reference that points to another file or URL, and a swagger: "2.0" document are warnings as well. A definition with no servers array is a note: consumers fall back to the OpenAPI default URL.

A version string that is present but not 3.x, such as "3" or "4.0.0", is a warning rather than an error, so a definition that is nearly right still produces a full report.

Reading the report

~1 in a pointer stands for a slash inside a path, so /paths/~1orders~1{id}/get is GET /orders/{id}. All findings from one run are listed together, so a document with several problems does not have to be validated over and over.

webhooks and components.pathItems are allowed by OpenAPI 3.1 and are not counted as operations. An empty paths object is valid and passes.

What the validator does not decide

Only structure and local references are checked. Security schemes, tag conventions, naming style and whether the API design is sound are out of scope, and nothing is requested from a live server. Two operations that share the same operationId are not reported.

Inside sample data — the content of example, the value of an examples entry, an enum or a const — the key $ref is treated as data rather than as a reference, so a payload that happens to contain it does not produce a false error.

Recent tools: