Swagger Validator — Swagger 2.0 & OpenAPI 3.x

Validate Swagger 2.0 and OpenAPI 3.x specs. Required keys, path operations, and response blocks — all checked client-side with line-anchored errors.

Input Swagger / OpenAPI (JSON or YAML)

Validation Result

What is a Swagger validator?

A Swagger validator checks that an API specification — written in Swagger 2.0 or OpenAPI 3.x — is structurally well-formed before tools like Swagger UI, openapi-generator, AWS API Gateway, or contract testers consume it. It catches missing version fields, missing info.title, empty paths, paths that don't start with /, and operations without a responses block.

Swagger 2.0 was the original spec; OpenAPI 3.0 (2017) and 3.1 (2021) are its successors. The 3.x line aligned with JSON Schema — 3.1 fully adopts JSON Schema 2020-12. This validator is permissive about which version you use: it focuses on rules common to all of them.

How to validate a Swagger spec — 4 steps

Paste your spec. Copy a Swagger 2.0 or OpenAPI 3.x document (JSON or YAML) into the Input panel.
Click Validate. The tool parses the document in JavaScript and runs structural checks.
Read errors. Each issue lists the closest source line and a one-line reason — e.g. Line 12: GET /pets: missing responses block.
Fix and re-run. When the badge turns green, your spec passes the universal structural checks.

Sample input and output

Input — Pet Store snippet

swagger: "2.0"
info:
  title: Pet Store
  version: 1.0.0
paths:
  /pets:
    get:
      summary: List pets
      responses:
        '200':
          description: OK

Output — Validation result

Valid Swagger 2.0 specification.

0 errors, 0 warnings.

All required keys present, every
operation has a responses block.

Structural rules the validator enforces

1. Version field

Every spec must declare swagger: "2.0" or openapi: "3.x.x" at the root.

2. info object

info.title and info.version are mandatory — they appear in every code generator output, in Swagger UI's header, and in API gateway metadata.

3. paths object

At least one path is required, every path key must start with /, and every operation (get/post/put/...) must have a responses block with at least one status.

4. Documentation hints (warnings)

Operations without a summary, description, or operationId emit a warning — the spec is valid but the docs and generated SDKs will be hard to navigate.

Universal Coverage

Works for Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1 — auto-detects the version from the root field.

Line-Anchored Errors

Every issue lists a source line number so you can jump straight to the problem in your editor.

Client-Side Only

Specs are parsed in JavaScript inside your browser. Internal endpoints and example tokens never leave your device.

Common use cases

check_circleAPI documentation generation — Swagger UI / Redoc / Stoplight Elements all reject malformed specs
check_circleContract testing with Pact, Dredd, or Schemathesis (each enforces a structural baseline)
check_circleClient SDK generation with openapi-generator or swagger-codegen
check_circleValidation step in CI before deploying to AWS API Gateway, Azure APIM, or Kong
check_circlePre-commit hooks for repos that ship an openapi.yaml file
check_circleCatching pasted-in spec snippets that lost their info or paths
check_circleReviewing vendor-supplied specs before importing into Postman
check_circleAuditing legacy Swagger 2.0 specs before migrating to OpenAPI 3.x

Swagger 2.0 vs OpenAPI 3.0 vs OpenAPI 3.1 vs AsyncAPI

Spec	Year	Schema dialect	Use for
Swagger 2.0	2014	Custom subset	Legacy APIs; widespread enterprise use
OpenAPI 3.0	2017	JSON Schema (subset)	Modern REST APIs; widest tooling
OpenAPI 3.1	2021	JSON Schema 2020-12	New projects; webhooks, full JSON Schema
AsyncAPI	2017	JSON Schema	Event-driven APIs (Kafka, MQTT, AMQP)

Need OpenAPI 3.x-specific checks?

The OpenAPI Validator goes deeper for 3.0/3.1: $ref resolution, security schemes, response status enforcement.

OpenAPI Validator OpenAPI to JSON OpenAPI to YAML

Frequently Asked Questions

What does the Swagger validator check?

It verifies the structural rules every Swagger 2.0 / OpenAPI document must satisfy: presence of the version field (swagger: "2.0" or openapi: "3.x"), info.title, info.version, at least one path under paths, every path key starting with "/", and every operation (get, post, put, etc.) having a responses block. It also warns when operations lack a summary, description, or operationId.

Does it accept both JSON and YAML?

Yes. The validator auto-detects format — input starting with "{" is parsed as JSON, otherwise as YAML. Most teams hand-edit specs in YAML and the validator handles both flavours equally.

What is the difference between Swagger and OpenAPI?

Swagger 2.0 (released 2014) was donated to the Linux Foundation and rebranded as OpenAPI 3.0 in 2017. The Swagger name now refers to the tool ecosystem (Swagger UI, Swagger Editor, Swagger Codegen) while OpenAPI refers to the specification itself. This validator handles both Swagger 2.0 and OpenAPI 3.x.

Is this a full schema validator?

No. It checks the most common structural rules — the ones that break Swagger UI, code generators, and gateway imports. For full JSON-Schema-based validation against the official OpenAPI meta-schema, use spectral, openapi-validator (IBM), or redocly lint locally.

Why does it report line numbers when YAML and JSON have different structure?

The validator scans the raw input text for the first occurrence of the problematic key (e.g. the path "/pets" or the field "info") and reports that line. The number is approximate but jumps you close enough to fix the issue in your editor.

Will my spec be uploaded to a server?

No. The validator runs entirely in JavaScript inside your browser. Specs containing internal hostnames, example bearer tokens, or proprietary endpoints never leave your device — verify in your browser DevTools Network tab.

How does this differ from the OpenAPI Validator on this site?

The Swagger Validator is more permissive: it accepts both Swagger 2.0 and OpenAPI 3.x, and focuses on universal structural rules. The OpenAPI Validator is OpenAPI 3.x-specific and adds checks for $ref resolution, security schemes, and per-response status codes.

Why do I get "missing responses" warnings?

OpenAPI requires every operation to declare at least one response — the spec is not valid otherwise. Code generators and Swagger UI will refuse to render an operation without a responses block. Add a default 200 (or 204 for empty) and the warning disappears.