OpenAPI Validator

Validate OpenAPI 3.0, 3.1, and 3.2 specifications in JSON or YAML. Check schema validity, local $refs, and evaluate MCP agent readiness.

Choose an OpenAPI fileMaximum 2 MB. The file stays in this browser tab.OpenAPI JSON or YAML

openapi: 3.1.0
info:
  title: Example Users API
  version: 1.0.0
servers:
  - url: https://api.example.com
paths:
  /users/{id}:
    get:
      operationId: getUser
      summary: Get a user
      description: Returns one user by its stable identifier.
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: string }
      responses:
        "200":
          description: User record
          content:
            application/json:
              schema:
                type: object
                required: [id, email]
                properties:
                  id: { type: string }
                  email: { type: string, format: email }
              example: { id: "usr_101", email: "ada@example.com" }
        "404":
          description: User not found

Loading tool module...

About this openapi validator

This API linter validates OpenAPI 3.0.x, 3.1.x, and 3.2.x specifications against official version-specific JSON Schemas. It parses JSON and YAML documents, validates local internal references, and conducts deterministic design and MCP-readiness checks to help teams build reliable, agent-compatible APIs. All validation happens locally in your browser tab.

OpenAPI specification validation methodology

OpenAPI specification validation proceeds through two distinct layers. Structural validation confirms that the document conforms to the official JSON Schema meta-schema for the declared OpenAPI version: required fields exist, enum values are from the allowed set, referenced components are properly typed, and all $ref JSON Pointers resolve to a schema within the document. Semantic and quality validation then checks whether the structurally-valid document follows good API design practice: operations have unique operationIds, path parameters declared in the URL appear in the parameter list, responses include at least one error status code, schemas have meaningful descriptions, and examples validate against their containing schema.

API contract testing and conformance verification

An OpenAPI document is a specification artifact—it describes what an API should do but cannot prove that a running implementation behaves correctly. API contract testing tools such as Schemathesis (property-based testing), Dredd (example-based testing), and Pact (consumer-driven contract testing) generate or replay test cases derived from the specification and compare actual server responses against documented schemas and status codes. A clean validation report from this tool is the starting point for contract testing; it ensures the specification itself is coherent before automated test generation begins. Always run contract tests against a deployed instance of the real API in a staging environment before promoting to production. It parses JSON and YAML documents, validates local internal references, and conducts deterministic design and MCP-readiness checks to help teams build reliable, agent-compatible APIs. All validation happens locally in your browser tab.

Worked path-parameter check

If a path is /users/{id} but neither the Path Item nor operation declares an id path parameter, the report marks a blocking mismatch.

If the same operation is structurally valid but has no error response or usable description, the document remains valid with review notes rather than being mislabeled invalid.

Specification validity and API quality differ

A schema-valid OpenAPI document can still be difficult for people, SDK generators, mock servers, and agents. CZOA reports missing operation IDs, weak descriptions, absent error responses, missing examples, undeclared security on writes, deep schemas, and oversized MCP tool sets separately.

Private validation boundaries

Uploaded files and pasted text stay in the browser and are limited to 2 MB.
Local JSON Pointer references are checked.
External references are reported but not downloaded, so multi-file specifications require a dedicated bundling workflow.
A clean report does not test the live server or prove that implementation behavior matches the document.

OpenAPI Specification · Content owner: CZOA Tools · Review methodology

How to use it

Paste an OpenAPI JSON/YAML document or choose a local file.
Run validation and resolve every blocking specification error first.
Review design warnings separately; not every warning is incorrect for every public API.
Validate the live implementation with contract tests before claiming that server behavior conforms.

Frequently asked questions

What does OpenAPI Validator check on a document?+

It parses JSON or YAML up to the visible 2 MB file limit, verifies supported OpenAPI 3.0.x, 3.1.x, or 3.2.x structure and local references, and separately reports operation and design issues. External references are reported rather than downloaded.

Can you show an input and its result?+

A one-operation OpenAPI 3.1 document for GET /ping produced Valid with review notes, one operation, zero blocking errors, and three warnings for missing description, error response, and response example.

How do validity and warnings differ?+

A document with zero structural errors may still receive warnings about documentation, examples, error responses, security, or MCP readiness. Warnings are review signals; neither a clean report nor a warning-free document proves a running API obeys the specification.

What result should the documented example produce?+

It does not call endpoints, fetch external $ref documents, authenticate to services, execute requests, test rate limits, or perform staging contract tests. Use a separate live test environment before claiming implementation conformance.