OpenAPI Validator

What Is an OpenAPI Validator?

An OpenAPI validator checks a specification document against the rules of the OpenAPI Specification. OpenAPI, formerly called Swagger, is the standard way to describe a REST API in a machine readable file: every endpoint, the parameters each one accepts, the request and response bodies, the data schemas, and the security requirements. This validator parses your JSON or YAML document, resolves every $ref pointer, and reports structural problems such as missing required fields, invalid data types, and references that point nowhere. Everything runs in your browser, so internal API designs never leave your machine.

Supported Versions

The validator accepts OpenAPI 3.0, OpenAPI 3.1, and the older Swagger 2.0 format. It detects the version from the openapi or swagger root field and validates against the matching official JSON Schema. OpenAPI 3.1 aligns fully with JSON Schema, while 3.0 uses a slightly modified dialect, and the validator applies the correct rules automatically in each case.

What Gets Checked

• Required root fields: the version declaration and the info object with its title and version must be present.
• Path and operation structure: every entry under paths must be a valid path item, and every operation must declare at least one response.
• Schema correctness: data types, required property lists, enums, formats, and numeric bounds are validated against the official schema definitions.
• Reference resolution: every local $ref using #/components/... or #/definitions/... must resolve to a real node in the document.
• Parameter rules: path parameters must be declared as required, and parameter locations must be one of path, query, header, or cookie.

How to Use the Validator

1. Paste your specification into the editor. Both JSON and YAML are accepted, and the sample button loads a complete example to try.
2. Validation runs automatically as you edit, so there is no button to press. Results appear within a moment of typing.
3. Read the status card. A green result confirms the document is valid and shows the detected specification version.
4. When something is wrong, each problem appears in the list below with the failing field path in parentheses, such as (at /paths/~1beans/get/responses).
5. When the document is valid, review the summary of paths, operations, and schemas to get a quick sense of the API surface.

Why Validate Before You Generate

OpenAPI documents feed a whole ecosystem: code generators that produce server stubs and client SDKs, documentation renderers like Swagger UI and Redoc, gateway configuration, and contract testing tools. A single typo in a $ref path or a missing response schema can break all of them downstream. Validating first catches those errors at the source, when they are a one line fix, instead of during code generation or, worse, at runtime in a gateway configuration. Treating validation as a required step in CI keeps the specification trustworthy as a source of truth.

Common Validation Errors and Fixes

• Missing info: add an info object with at least title and version fields.
• Unresolvable $ref: check the pointer path for typos, and confirm the target node exists under components or definitions.
• Path parameter not required: any parameter declared with in: path must also set required: true.
• Invalid type value: schema types must use JSON Schema names such as string, number, integer, boolean, array, and object.
• Empty responses: every operation needs at least one response entry, even if it is only a default error response.

Frequently Asked Questions

Related Tools

Convert a plain schema into a specification with the JSON Schema to OpenAPI Schema converter, tidy the JSON body with the JSON Formatter, validate individual payloads against a schema with the JSON Schema Validator, or draft realistic responses with the Mock API Response Generator.