What this validator checks
Paste or upload an OpenAPI 3.0 or 3.1 document as YAML or JSON and the validator reports the structural problems that actually break SDK and docs generation — not just whether the file parses. Everything runs in your browser; the spec never leaves your machine.
- Document basics: a supported
openapiversion,info.title,info.version,servers, and at least one path with operations. - Operation hygiene: missing or duplicate
operationIds — the number one cause of ugly generated SDK method names. - Responses: operations without a
responsesobject, without a success response, or with responses missing descriptions. - Parameters: path parameters that are undeclared, not marked
required, unused, or missing a schema. - References: unresolved local
$refpointers, and request bodies withoutcontent. - Version problems: Swagger 2.0 documents are flagged — convert them with the Swagger 2.0 to OpenAPI 3 guide first.
Common OpenAPI validation errors
Across real specs, the same handful of issues dominate: missing operationIds (generators fall back to synthesized names like getUsersUserId), path parameters declared in the URL template but not in parameters, $ref pointers to schemas that were renamed or never defined, and operations with no success response, which most docs renderers and SDK generators treat as an error. The report links each finding to a suggested fix, and you can copy the whole report for a teammate or a CI ticket.
When to use this page
Use this tool for a fast structural pass before you generate anything — it is the same class of checks Sourced runs at the start of its SDK and docs generation pipeline. If you are choosing a validator to run in CI, read the comparison of five OpenAPI validators tested on real specs — Spectral, Redocly CLI, openapi-cli, swagger-cli, and Sourced. And if you are deciding which spec version to validate against, see OpenAPI 3.1 vs 3.0.
Frequently asked questions
What does this OpenAPI validator check?
It parses OpenAPI 3.0 and 3.1 YAML or JSON and reports structural problems that break SDK and docs generation: missing or duplicate operationIds, operations without responses or success responses, path parameters that are undeclared, not required, or unused, parameters without schemas, unresolved $ref pointers, and request bodies without content.
Does it support OpenAPI 3.1?
Yes. It reads OpenAPI 3.0.x and 3.1.x documents. Swagger 2.0 documents are flagged with a pointer to convert them to OpenAPI 3 first.
Is my spec uploaded anywhere?
No. Validation runs entirely in your browser; the spec never leaves your machine.
When should I use a validator instead of a linter like Spectral?
Use this validator for a fast structural pass before generating SDKs or docs. Use Spectral or Redocly CLI in CI when you want an opinionated, configurable style guide on every commit. The two are complementary.