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.

What is the OpenAPI / Swagger Spec Validator?

Free OpenAPI and Swagger validator. Parses your YAML or JSON spec and checks the required structure — version, info, paths, operations, responses and parameters — reporting each issue with a JSON-pointer-style path. Client-side; the spec is never uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

OpenAPI / Swagger Spec Validator

Name: OpenAPI / Swagger Spec Validator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

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.

What the validator checks

Rule	Why it matters
Version field present (`openapi` or `swagger`)	Code generators and docs tools refuse to load without it
`info.title` and `info.version` present	Required by the spec; many tools display these
`paths` object exists	Without it the spec has no endpoints
Every operation has a `responses` object	Clients cannot handle replies from undocumented operations
Response keys are valid status codes or `default`	Invalid keys (e.g. `"20A"`) cause parse failures in generators
Inline parameters have `name` and `in`	Missing `in` is one of the most common silent bugs
OpenAPI 3.x parameters carry a `schema`	Required by 3.x spec; Swagger 2.0 uses `type` directly instead

Common validation failures and fixes

Missing responses on an operation. Every operation must have at least one response, even if it is just default. Add a minimal block:

responses:
  "200":
    description: OK

Invalid status code key. Status codes must be three-digit strings ("200", "404") or the literal default. A typo like "20A" or a bare integer like 200 (without quotes in YAML) is caught here.

Wrong version field. OpenAPI 3.x uses openapi: "3.0.3". Swagger 2.0 uses swagger: "2.0". Using the wrong key causes the tool — and many generators — to misidentify or reject the spec.

Parameter without in. The in field must be one of path, query, header, or cookie. Missing it entirely is a spec error that breaks client code generators.

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 JSON 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. For full schema validation including $ref resolution, run the spec through a dedicated tool like @redocly/cli or Spectral after confirming the structure here.