What does this validator check?

It checks the structural rules of the spec — the version field, a valid info object with title and version, a paths object, that every operation has a responses object, that response keys are valid status codes or default, and that inline parameters declare name and in. It catches the most common spec mistakes.

Does it accept both YAML and JSON?

Yes. JSON is parsed directly, and block-style YAML is parsed by a built-in parser covering the indentation, key-value, and list structures that appear in typical OpenAPI documents. Paste whichever format you have.

What is the difference between OpenAPI and Swagger?

Swagger 2.0 is the older specification, identified by a top-level swagger field set to 2.0. OpenAPI 3.x is the successor, identified by an openapi field like 3.0.3. This tool detects and validates either, and shows you which one it found.

Does it resolve external $ref references?

No. It validates the structure of the document you paste, including local references, but it does not fetch or dereference external files since everything runs in your browser. Parameters that are pure references are accepted as-is.

Is my API spec uploaded anywhere?

No. Parsing and validation happen entirely in your browser in JavaScript. The spec never leaves your device, which makes it safe for private or internal API definitions.

OpenAPI / Swagger Spec Validator

An OpenAPI (formerly Swagger) document describes a REST API in a machine-readable way: its endpoints, parameters, request bodies, and responses. Tools generate clients, servers, and docs from it — but only if it is structurally correct. This validator parses your YAML or JSON spec in the browser and checks it against the rules that the most common mistakes violate.

How it works

The tool runs in two stages:

Parse. If the input starts with { or [ it is parsed as JSON. Otherwise a built-in block-style YAML parser converts the document into an object, handling indentation, key: value pairs, lists, and inline scalars.
Validate. It then walks the object and applies the structural rules — version format, the required info.title and info.version, the paths object, and for each operation a responses object keyed by valid status codes or default. Inline parameters must declare name and in, and OpenAPI 3.x parameters are expected to carry a schema.

Every problem is reported with a JSON-pointer-style path such as paths/pets/get/responses, so a long spec is quick to fix.

Example

A response block keyed by an invalid code is caught:

responses:
  "20A":      # invalid — not a status code
    description: Bad

The validator flags paths/.../responses/20A: invalid status code key. A valid spec instead uses "200", "404", or default.

Notes

This is a structural validator, not a full schema validator with external $ref resolution. It catches the errors that break code generators and doc tools — missing responses, malformed versions, parameters without a name — while keeping your spec entirely on your own device.