OpenAPI Spec Validator

About the OpenAPI Spec Validator

Most teams generate or hand-write an OpenAPI document, then never run it through a linter until a client SDK breaks in production. This tool gives you a fast, browser-only first pass: paste your OpenAPI 3.0 or 3.1 spec in JSON or YAML, get a structural validity check, an endpoint-by-endpoint summary, and a prioritized list of common issues — missing operationIds, undeclared path parameters, missing 401/403 responses on authenticated endpoints, write operations without 400/422 validation responses, response objects without descriptions, and request bodies with no examples.

Three strictness levels let you focus on what matters for your stage of API maturity: Basic for early drafts, Recommended for production review, and Strict for SDK-ready specs. No spec ever leaves your browser.

Does this tool validate against the full OpenAPI 3.1 JSON Schema?

Not in full — it implements a pragmatic subset focused on issues that actually cause SDK generation failures, broken docs and security gaps in production. We check required root fields (openapi version, info.title, info.version), path parameter declarations, HTTP method casing, response code coverage, request body structure for write operations, and security/response correlation. For full IETF-grade schema validation against the official meta-schema, run a CI step with tools like Spectral, Redocly CLI, or vacuum after this browser pass — they download the JSON Schema and run thousands of structural rules. The browser tool is your daily-driver review pass; CI is your gate.

Why are 401 and 403 responses flagged as missing when my endpoint clearly requires authentication?

Because clients, SDK generators and API explorers need explicit response shapes to handle errors correctly. Declaring `security: [{bearerAuth: []}]` tells the spec engine that authentication is required, but if you only document `200: OK` in responses, the generated SDK has no typed shape for the 401 body — so on a token expiry the client throws an opaque parsing error instead of surfacing a typed AuthError. Add at least `401: { description: Invalid or missing token }` and ideally a schema with `code`, `message` fields. For role-based endpoints (POST/PUT/DELETE/PATCH) also add 403 Forbidden so the SDK can distinguish 'unauthenticated' from 'wrong permission'. Disable the check in the toolbar if you handle auth errors uniformly at a gateway and never expose them per-endpoint.

What's the difference between OpenAPI 3.0 and 3.1, and does this validator handle both?

OpenAPI 3.1 aligns the schema vocabulary with JSON Schema 2020-12: `nullable: true` is replaced by `type: [string, null]`, `exclusiveMinimum/Maximum` become numbers instead of booleans, `example` is now `examples` (array), webhooks become first-class, and `$ref` can sit alongside sibling keywords. The validator detects either 3.0.x or 3.1.x via the `openapi` field and applies the same structural checks (the lint rules in this tool overlap heavily between versions). If you mix conventions — e.g., `nullable: true` in a spec declared `openapi: 3.1.0` — most tools tolerate it but the SDK output may surprise you. For multi-version codebases, settle on one major version per repo.

Why does the YAML parser fail on some specs but the JSON version works fine?

We ship a deliberately small YAML parser (no anchors, no merge keys `<<`, no tags `!!type`, no multi-document `---` streams) to keep the tool offline and lightweight. ~95% of real OpenAPI specs we tested parse fine, but specs heavy on YAML anchors (commonly used to dedupe shared response shapes) will fail. Two workarounds: (1) export your YAML to JSON via `npx js-yaml spec.yaml > spec.json` and paste the JSON — full anchor expansion happens at conversion time; (2) inline the anchors manually. The error message will point at the line. Long term, if you need full YAML support, run a desktop linter like Spectral or Redocly CLI which use full js-yaml internally.

What does 'undeclared path parameter' mean and why does it break clients?

When your path template includes `{petId}` (or any other `{name}`), each placeholder must appear in the operation's `parameters` list with `in: path` and `required: true`. If `{petId}` is in the URL but missing from parameters, code generators like openapi-generator, oapi-codegen, Kiota and openapi-typescript can't produce a typed argument for the method — they either skip the operation, emit a method that takes no arguments and hardcodes a literal `{petId}` into the URL, or crash entirely. The validator finds both directions: parameters in the URL but undeclared, and parameters declared in `parameters` but not present in the path. Fix by adding the missing declarations or by removing stale ones — the URL is the source of truth.

Should every operation have a unique operationId, and what naming convention is best?

Yes — code generators use operationId as the method name in client SDKs. Without it they synthesize one from method + path, producing names like `getPetsPetId` that are ugly and unstable across spec edits. Convention: verb + resource + qualifier, in camelCase: `listPets`, `getPet`, `createPet`, `updatePet`, `deletePet`, `searchPets`, `getPetVaccinations`. Keep operationIds globally unique across the whole spec (some generators namespace by tag, many don't). For paginated lists prefer `listPets` over `getPets` to signal multiplicity. For batch endpoints use `bulkCreatePets`. The validator flags missing operationIds at WARN severity — fix them before any external client consumes your spec.

Is this validator suitable for AI-generated OpenAPI specs (LLMs producing API definitions)?

Especially well suited. LLM-generated OpenAPI specs (from prompts like 'design an API for X') consistently hit the same pitfalls: response descriptions missing, path params declared but not in URL or vice versa, lowercase methods mixed with uppercase, 401 responses missing on secured ops, request bodies with examples but no schema, and forgotten error responses. Paste the LLM output here as your first sanity check before feeding it to a code generator or doc tool. The combination of structural validation + endpoint table + lint warnings catches roughly 80% of LLM hallucinations in our internal testing on Claude, GPT-4, and Gemini outputs. After passing this tool, run a deeper schema check in CI before publishing.

Does the tool support Swagger 2.0 or only OpenAPI 3.x?

Swagger 2.0 specs (`swagger: "2.0"` at the root) are detected and flagged with an upgrade recommendation — the tool does not run lint rules on them. Swagger 2.0 hit feature freeze in 2014 and the broader ecosystem (Spectral, Redocly, Stoplight, Postman, AWS API Gateway, Apigee, Kong) all favor OpenAPI 3.x. Convert with `swagger2openapi spec.json` (npm package) which handles 90%+ of the migration automatically: parameter `body` types move into requestBody, definitions move to components.schemas, and `host`/`basePath`/`schemes` collapse into the servers array. After conversion, paste here to lint the result before merging.