OpenAPI / Swagger Validator

Paste an API spec and get every structural problem listed with an exact JSON-pointer path — right in your browser, nothing uploaded. It understands both OpenAPI 3.x (the openapi: field) and Swagger 2.0 (the swagger: field), and accepts either JSON or YAML input; the format is auto-detected from the first non-whitespace character.

This is not a full re-implementation of the official OpenAPI JSON Schema — it targets the mistakes that actually break API specs in practice:

• Document shape: a version field (openapi or swagger) is present, info.title and info.version are set, and paths exists and is an object.
• Version-specific hints: OpenAPI 3.x specs are checked for a non-empty servers array; Swagger 2.0 specs are checked for host or basePath.
• Operations: every key under a path item is either a recognized HTTP method (get, post, put, delete, patch, options, head, trace) or a legal sibling (parameters, summary, description, servers, $ref) — anything else is flagged. Each operation is checked for a responses object and a non-empty operationId, and operationId values must be unique across the whole document.
• Path parameters: every {param} placeholder in a path template (like /pets/{petId}) must be declared in parameters with in: path and required: true — a mismatch here is one of the most common spec-authoring bugs, and it's easy to miss by eye in a long file.
• $ref resolution: every local $ref (#/components/schemas/Pet, #/definitions/Pet, etc.) is walked as an RFC 6901 JSON Pointer to confirm it actually resolves to something in the document. External/remote refs (URLs, other files) aren't fetched — this runs as a pure function with no network access — so they're left unchecked rather than reported as broken.

How to use it

1. Paste your OpenAPI or Swagger spec — JSON or YAML — into the input box, or click Try an example to load a sample.
2. Read the Result line for the pass/fail summary: it reports the detected spec type and version, endpoint count, schema count, and the error/warning tally.
3. Scan the Issues table for details. Each row has a Severity (error or warning), a Path in JSON-pointer form, and a plain-English Message. Errors are things that break the spec's contract (a missing responses object, a duplicate operationId); warnings are best-practice gaps (no servers block) that don't invalidate the document.

Validation re-runs automatically as you type.

Errors vs. warnings — what's the difference?

Errors mean the document is structurally broken or ambiguous — a client or code generator reading it would either fail or guess wrong (a path parameter with no declared type, a $ref pointing at nothing). Warnings flag missing best practices that most tooling tolerates (no servers array in an OpenAPI 3.x spec still parses fine — it just leaves the base URL unspecified).

Why doesn't it validate every field, like nullable types or schema constraints?

Fully validating a spec's embedded JSON Schemas (the properties, type, enum, etc. inside components.schemas) is a separate, much larger problem — that's what a generic JSON Schema Validator is for. This tool focuses on the OpenAPI/Swagger document's own required structure: the top-level openapi/info/paths/components shape that every OpenAPI-aware tool depends on, not the arbitrary schemas a spec author nests inside it.

Does it check remote $refs or external files?

No. A $ref that points outside the document (a URL, or otherfile.yaml#/Pet) can't be resolved without a network request, and this validator is a pure, offline function — the same code runs in your browser, the API, and the CLI without ever making an outbound call. Only refs starting with #/ (pointing back into the same document) are checked.

Is my spec private?

Yes. Parsing and validation happen entirely in your browser (or in the API/Node runtime if you call it programmatically) — nothing is uploaded or stored.