OpenAPI Validator

Runs in browser Web

Check required fields, path/operation structure, parameter definitions, unresolved $ref references, duplicate operationIds, missing responses and common mistakes in OpenAPI / Swagger specs.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What is API contract testing?

An API contract is the agreed description of an interface — its endpoints, parameters, request and response schemas and status codes — usually written as an OpenAPI document. Contract testing compares what a service actually returns with that description, so a renamed field or a changed type is caught by the producer or the consumer before it breaks the other side.

Read the guide: What is API Testing? How to Test a REST API

How to use OpenAPI Validator

  1. Paste the specification.
  2. Read the status line, then fix errors first (they break tooling) and warnings second.
  3. Download the problem table as CSV to track fixes in a review.

OpenAPI Validator features

  • OpenAPI 3.0, 3.1 and Swagger 2.0 in JSON or YAML with line-accurate parse errors
  • Required fields, servers/host syntax, path templates vs. path parameters, parameter locations, request bodies and responses
  • Duplicate operationIds, unresolved local $ref pointers, unused components, undefined security schemes, unused or undeclared tags
  • Schema checks: unknown types, arrays without items, min/max ordering, required properties that do not exist, 3.0 nullable vs 3.1 type arrays
  • Problems sorted by severity with JSON Pointer locations
  • Document statistics: paths, operations, parameters, responses, schemas, security schemes, tags, servers

OpenAPI Validator example

Catch a broken path parameter (output shortened)

Input:

paths:
  /orders/{orderId}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: string }
      responses:
        "404": { description: Not found }

Output:

error  #/paths/~1orders~1{orderId}/get/parameters/0/name  Path parameter "id" does not appear in the path template "/orders/{orderId}".
error  #/paths/~1orders~1{orderId}/get/parameters  Path template uses {orderId} but no path parameter "orderId" is defined.
warning  …/responses  No 2xx or default response is documented.
A location in the Problems table is a JSON Pointer: follow it segment by segment from the root, reading each ~1 as a /, to reach the failing line.

Location (JSON Pointer)

Part 1:#/Part 2:paths/Part 3:~1orders~1{orderId}/Part 4:get/Part 5:parameters/Part 6:0/Part 7:name

Where it points in the YAML

Part 2:paths:
  Part 3:/orders/{orderId}:
    Part 4:get:
      Part 5:parameters:
        Part 6:- Part 7:name: id
          in: path
          …
  1. 1Document root
  2. 2The paths object
  3. 3The path /orders/{orderId}A / inside a key is written ~1 (RFC 6901), so it is not read as a separator
  4. 4The operation
  5. 5Its parameter list
  6. 6The first itemArray positions count from 0
  7. 7The field with the problemPath parameter "id" does not appear in the path template "/orders/{orderId}".Fail

The first location in the example output above; the tool reports the same pointer.

Frequently asked questions about OpenAPI Validator

What is checked?

Required top-level fields (openapi/swagger, info.title, info.version, paths), server and host syntax, path templates vs. path parameters, parameter locations and required flags, request bodies, responses with descriptions and valid status codes, duplicate operationIds, unresolved local $ref pointers, unused components, security requirements that reference undefined schemes, tag consistency and schema keyword sanity (array items, min/max ordering, 3.0 vs 3.1 nullability).

What is the difference between errors, warnings and hints?

Errors violate the specification and will break code generators or gateways. Warnings are allowed but risky or unhelpful (missing operationId, no 2xx response, unused schema). Hints are documentation-quality suggestions.

Does it validate examples against schemas?

No. Validation is structural. Use the JSON Schema Validator tool to check example payloads against an individual schema.

Are external $ref files fetched?

No. References to other files or URLs are reported as unverifiable hints; everything else is validated offline in your browser.

Technical notes

Locations are JSON Pointers (RFC 6901) with ~1 escaping for slashes so they can be used directly with other tooling. The validator is structural and deliberately fast (single pass, no network), which makes it suitable for live validation while editing.

References

  • OpenAPI SpecificationOpenAPI InitiativeThe standard for describing REST APIs: paths, operations, parameters, schemas, responses and security schemes.
  • JSON Schema SpecificationJSON SchemaThe vocabulary for describing and validating the shape of JSON documents (types, required properties, formats).
  • RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.