OpenAPI / Swagger Validator

Paste an API spec, upload a file, or fetch one from a URL, and get every structural problem listed with an exact JSON-pointer path. 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. Provide the spec one of three ways: paste it — JSON or YAML — into the input box, upload a .json/.yaml/.yml file, or enter a URL to fetch it from. Click Try an example to load a sample. If a URL is set, it takes priority over the pasted/uploaded spec.
2. Click Validate spec.
3. 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.
4. 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.

Fetching from a URL

The URL is fetched server-side (not from your browser) — that's what lets it reach any public spec URL without running into CORS. The fetch has a 10-second timeout and an 8 MB response cap (pasting or uploading the spec instead allows up to 10 MB), and requests to localhost, private/internal IP ranges, and cloud metadata endpoints are blocked.

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?

Parsing and validation run server-side and nothing is stored afterward. If you use the URL field, that URL is fetched by our server (not your browser) and its content is sent to us to be parsed — the same as any tool that fetches a page on your behalf.