← All guides

Validating an OpenAPI or Swagger Spec: What Structural Checks Catch (and What They Don't)

Full OpenAPI conformance validation means checking a document against the OpenAPI meta-schema — every parameter type, every format keyword, every constraint. That's a legitimately large validation surface, and it's not what this tool does. Instead it checks the smaller set of things that make a spec usable rather than fully spec-compliant: does it declare a version, does every operation have responses, are there duplicate operation IDs, does every internal reference actually resolve. Those four checks catch the mistakes that break codegen and documentation tools, which is a more common failure mode day-to-day than a subtly wrong format keyword.

Errors vs. warnings — the distinction is deliberate

Not every issue gets the same severity. A path object with no HTTP methods declared is a warning — unusual, but not necessarily broken, since some tooling uses path-only entries for documentation grouping. An operation with no responses object is an error, because every OpenAPI operation is required to declare at least one response. If you're scanning results programmatically, filter on level rather than treating every entry in the issues list as a hard failure.

Everything is collected, nothing stops the scan early

The validator walks the entire document and gathers every issue it finds before returning — it doesn't bail out on the first missing field. That matters for a real spec with a dozen endpoints: fixing one problem, re-pasting, and discovering the next one field-by-field is a slow loop. Getting the whole list on the first pass means you can fix everything in one editing session instead of one round-trip per bug.

Advertisement

What counts as a dangling $ref, precisely

A $ref is resolved by splitting it on / and walking the document object key-by-key — #/components/schemas/User means "does doc.components.schemas.User exist." If any segment along that path is missing, it's flagged. This only works for internal references starting with #/. A ref pointing at another file (./schemas/user.yaml#/User) or an external URL can't be checked from a single pasted document with no filesystem access, and is silently skipped rather than falsely flagged as broken — a false "dangling ref" on a perfectly valid external reference would be worse than no check at all.

YAML in, no conversion step needed

Most real OpenAPI specs are written in YAML, not JSON, so this validator parses YAML directly — paste your openapi.yaml as-is. YAML parsing is loaded as a dynamic import rather than bundled into the page's initial JavaScript, since most visitors to other tool pages never touch this one; it's pulled in only when you actually load this page.

Advertisement

Try the OpenAPI / Swagger Validator