Swagger 2.0 Validator

What counts as a Swagger 2.0 pass

For a 2.0 file, the version check is satisfied by a top-level swagger key. The tool does not verify that its value is "2.0", so it will not catch a wrong number. Beyond the version, it needs info.title, info.version and a paths object.

Fields that are specific to Swagger 2.0, such as host, basePath, schemes, definitions and securityDefinitions, are not examined. A missing host or a broken definitions block will not be reported.

A worked example

{
  "swagger": "2.0",
  "info": { "title": "Shop API", "version": "1.0" },
  "paths": {
    "/products": {
      "get": { "summary": "List products" },
      "x-internal": true
    }
  }
}

The version field, info and paths are all there, so there are no errors. The report shows one warning:

The document is still reported as valid, because warnings do not block validity. Vendor extension keys like x-internal are legal in Swagger 2.0, so you can leave it in place.

Migrating from 2.0

If you plan to move to OpenAPI 3.x, you can paste the converted file into the same box and compare results. The check is the same, with the openapi field replacing swagger. Run a full converter and linter for the real migration work, since this tool does not translate definitions or host settings.

When a quick check is enough

Swagger 2.0 definitions often live for years in repositories and get edited by hand. A fast structural check is useful when you inherit one, when a tool refuses to load it and you suspect a missing field, or when you merge two files and want to be sure the result still has its info and paths sections. For the full 2.0 rules, including definitions and security settings, follow up with a dedicated linter.

Keep in mind that a clean report is a statement about structure only. Operations without responses, wrong parameter types and unresolved references are outside this check, so test the file in your documentation or code generation tool as well.