OpenAPI Validator

Validate OpenAPI 3.0 / 3.1 and Swagger 2.0 specs against the official schemas — YAML or JSON, entirely in your browser.

OpenAPI / Swagger YAML or JSON

openapi: "3.0.0"
info:
  title: Sample API
  version: "1.0.0"
  description: A sample API to demonstrate OpenAPI validation
paths:
  /users:
    get:
      summary: List users
      operationId: listUsers
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/User"
  /users/{id}:
    get:
      summary: Get user by ID
      operationId: getUser
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/User"
        "404":
          description: Not found
components:
  schemas:
    User:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
        name:
          type: string
        email:
          type: string

Loading validator…

OpenAPI Validator — check OpenAPI 3.0/3.1 and Swagger 2.0 specs against the official schemas

OpenAPI (formerly Swagger) is the industry standard for describing REST APIs. Unlike a hand-rolled field checker, this tool validates your document against the official OpenAPI meta-schemas — Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1 — using a real, spec-compliant JSON Schema engine (@cfworker/json-schema), so it enforces the full structure: the info object, paths and operation shapes, parameter and request-body objects, response content, and component definitions. It auto-detects the version from your openapi/swagger field, reports each problem as a JSON Pointer, resolves every internal $ref (both 3.x #/components/… and Swagger 2.0 #/definitions/…) to make sure it points at something real, and flags operations missing an operationId. Both YAML and JSON are accepted, and everything runs locally in your browser — no server, no eval.

Built and maintained by Meet Shah · Last updated 25 July 2026

What this tool is used for

Catching a broken reference before a code generator produces something unusable.
Checking a hand-edited spec after a merge that touched several paths.
Confirming a Swagger 2.0 document is well-formed before converting it.
Finding a duplicated operation id that a generator will silently collapse.
Reviewing a spec from a partner before building against it.

Frequently Asked Questions

What changed between OpenAPI 3.0 and 3.1?: 3.1 aligned with JSON Schema 2020-12, so `nullable: true` was replaced by a type array `["string", "null"]`, and webhooks became first-class. That schema alignment is the substantive change — 3.0's schema dialect was a near-miss subset that caused constant tooling friction.
What does a validator actually check?: That the document conforms to the specification — required fields, valid references, correct types. It cannot check that the description matches the implementation, which is the far more common failure and needs contract testing to catch.
Why do $ref resolution errors happen so often?: Because references are URI-based and a relative path resolves against the document's own location. A spec split across files works in one tool and fails in another depending on how each resolves the base — which is why bundling before validating is common practice.
Should the spec be written first or generated from code?: Design-first keeps the contract independent and reviewable before implementation; code-first guarantees the spec matches what ships. The failure mode differs: design-first drifts from reality, code-first documents whatever accidentally exists.
Is Swagger the same as OpenAPI?: Swagger was the original name up to version 2.0; the specification was donated to the OpenAPI Initiative and renamed from 3.0 onward. Swagger now refers to SmartBear's tooling, so a Swagger 2.0 file is a real format and a Swagger 3.0 file is a misnomer.

Common errors and gotchas

Treating a valid spec as an accurate one. Validation checks the document, not whether the API behaves that way.
Leaving a dangling `$ref` after moving a schema, which validates as a reference and resolves to nothing.
Reusing an operation id, which generators use for method names and will overwrite.
Mixing 2.0 and 3.x constructs after a partial migration, where each half looks plausible.
Assuming examples are checked against their schemas. Many validators do not verify that at all.