OpenAPI Validator

Paste an OpenAPI or Swagger document, in JSON or YAML, and this validator checks its core structure. It confirms the document parses, that it carries an openapi or swagger version field, an info object with a title and version, and a paths object, then flags paths that do not start with a slash and unknown HTTP methods. It is a fast structural check, not a full JSON Schema validator.

How validation runs

  1. 1

    Paste the document

    JSON or YAML, for OpenAPI 2 (Swagger) or OpenAPI 3.

  2. 2

    Parse it

    The validator parses the document as JSON, and falls back to a YAML parse if that fails.

  3. 3

    Check the required fields

    It confirms an `openapi` or `swagger` version field, an `info` object with `title` and `version`, and a `paths` object.

  4. 4

    Scan the paths

    Each path is checked for a leading slash, and each operation key is checked against the known HTTP methods.

  5. 5

    Read the report

    Errors block validity; warnings point out paths without a leading slash and unknown methods.

What this validator checks

Check Result if it fails
Document parses as JSON or YAML Error
openapi or swagger field present Error
info object present Error
info.title present Error
info.version present Error
paths object present Error
Each path starts with / Warning
Operation keys are known HTTP methods Warning

A document that clears every error is reported as structurally valid. Warnings do not block validity; they highlight things worth fixing.

What it does not check

This is a structural check, not a full specification validator. It does not:

  • validate every node against the official JSON Schema for your version;
  • resolve $ref references or confirm the components they point to exist;
  • check that path parameters are declared and used consistently;
  • verify operationId values are present or unique;
  • report line numbers for errors.

For that depth, run a dedicated CLI validator such as redocly lint, swagger-cli validate or spectral lint. Use this tool for a quick sanity check before you commit or share a spec.

OpenAPI versions in the wild

Version Notes
Swagger 2.0 Still widely deployed; uses swagger: "2.0"
OpenAPI 3.0.x The most common 3.x line
OpenAPI 3.1.0 Aligns with JSON Schema 2020-12

This validator accepts either the openapi field (3.x) or the swagger field (2.0), so all of these pass the version check.

A minimal document that passes

openapi: 3.0.3
info:
  title: Example API
  version: 1.0.0
paths:
  /users:
    get:
      summary: List users

Every required field is present, the single path starts with a slash, and get is a known method, so this reports as structurally valid.

Frequently Asked Questions

Swagger was the original name of the specification, donated to the Linux Foundation in 2015 and renamed “OpenAPI” from version 3.0. “Swagger” now refers to the tooling (Swagger UI, Swagger Editor). The specification itself is OpenAPI. This validator accepts both the swagger (2.0) and openapi (3.x) version fields.

No. It checks the core structure: that the document parses, carries a version field, an info object with title and version, and a paths object, and it warns about paths without a leading slash and unknown methods. It does not validate every node against the official JSON Schema. Use redocly lint or spectral lint for that.

No. It does not follow $ref references or check that the components they point to exist. For cross-file references, bundle the document first with a tool like redocly bundle or swagger-cli bundle, then run a full validator.

No. It only inspects the document you paste, not your running code. It cannot tell whether your API actually returns what the spec describes. Contract-testing tools such as Dredd or Schemathesis do that.

Related Tools

Tool available in other languages