Does this validate against the full Swagger 2.0 JSON Schema meta-schema?

No. It runs a focused set of structural checks (required top-level fields, valid HTTP method keys, non-empty responses, path parameters that are actually declared, duplicate operationIds) rather than a full meta-schema validation, so it catches the mistakes that most commonly break tooling without needing to bundle the entire Swagger schema.

Does it support both JSON and YAML input?

Yes. The input is parsed as JSON first, and if that fails, as YAML, so you can paste either format without selecting one first.

What happens if I paste an OpenAPI 3.x document here instead?

It's detected and rejected with a message pointing you to the OpenAPI Validator, since a document with an "openapi" field instead of "swagger" needs the OpenAPI-specific checks instead.

What's the difference between an error and a warning here?

Errors are things that break codegen, validation, or routing outright, like a missing responses object or an undeclared path parameter. Warnings flag things that are technically valid but worth fixing, like a missing operationId or an unrecognized version string.

Swagger Validator - Check a Swagger 2.0 Spec for Common Errors

Overview

Introduction

A hand-edited Swagger 2.0 document is easy to get subtly wrong: a path parameter with no matching declaration, an operation with no responses object, two operations sharing an operationId.

This tool checks for exactly those mistakes and reports each one with its location in the spec, entirely in your browser.

What Is Swagger Validator?

A structural validator for Swagger 2.0 documents, accepting either JSON or YAML input.

It's part of this site's API Tools collection and runs entirely client-side. For OpenAPI 3.x documents, use the separate OpenAPI Validator instead.

How Swagger Validator Works

The document is parsed and checked for required top-level fields (a swagger version field, info.title, info.version, a paths object), then every operation under every path is checked for a valid HTTP method key, a non-empty responses object, and path parameters that actually have a matching parameter definition.

Every operationId encountered is tracked so a duplicate can be reported against both locations that use it.

When To Use Swagger Validator

Use it after hand-editing a Swagger 2.0 document, before feeding it to a code generator or API gateway that will fail cryptically on a structural mistake.

It's also useful for spot-checking a legacy Swagger spec pulled from a third party before trusting it in your own tooling.

Often used alongside OpenAPI Validator, Postman to OpenAPI Converter and OpenAPI to Postman Converter.

Features

Advantages

Catches the specific mistakes that most commonly break codegen and routing tools, not just generic JSON/YAML syntax errors.
Reports each issue's location in the document (as a dotted path) alongside a plain-language explanation.

Limitations

Doesn't perform full JSON Schema validation against the Swagger meta-schema, so some deeper structural mistakes may go unreported.
Doesn't resolve $ref pointers, so an issue hidden behind a reference to another file or section won't be checked.

Examples

An undeclared path parameter

Input

paths: {"/users/{id}": {get: {responses: {"200": {description: "ok"}}}}}

Output

Error at paths./users/{id}.get: Path parameter "{id}" has no matching "in: path" parameter definition.

The path template declares {id}, but no parameters array anywhere on that operation or path item declares an in: path parameter named id.

A missing responses object

Input

paths: {"/ping": {get: {operationId: "ping"}}}

Output

Error at paths./ping.get.responses: Missing required, non-empty "responses" object.

Every operation must declare at least one response, since tooling relies on it to know what a successful (or error) call returns.

Best Practices & Notes

Best Practices

Run this after any manual edit to a spec, since path-parameter and responses mistakes are easy to introduce silently.
Add an operationId to every operation, even though it's only a warning here; a missing one causes real problems in most code generators.
Consider migrating actively-maintained specs to OpenAPI 3.x, since Swagger 2.0 is a predecessor format with no further updates planned.

Developer Notes

Path parameters are detected with a `{([^}]+)}` match against each path template segment, then cross-checked against the union of path-item-level and operation-level `parameters` arrays filtered to `in: "path"`, which mirrors how Swagger actually resolves parameter inheritance between a path item and its operations. The check logic is shared with the OpenAPI Validator through a common core parameterized by which version field to expect.

Swagger Validator Use Cases

Validating a hand-written or hand-edited Swagger 2.0 spec before running it through a code generator
Checking a third-party API's published legacy spec for the kind of mistakes that break client generation
Finding duplicate operationIds introduced by copy-pasting an operation and forgetting to rename it

Common Mistakes

Assuming a spec that passes here is fully valid; it targets common, high-impact mistakes, not full meta-schema conformance.
Declaring a path parameter only in a $ref-referenced shared parameters file, which this validator doesn't resolve.

Tips

Fix errors before warnings; warnings like a missing operationId won't break tooling the way an undeclared path parameter will.

Swagger Validator