OpenAPI 3.x Schema Validator

OpenAPI 3.x (formerly known as Swagger 3) is the current standard for describing RESTful APIs. It replaced Swagger 2.0 with a cleaner structure: the top-level field changed from "swagger: \"2.0\"" to "openapi: \"3.0.x\"", request bodies were separated from parameters, and components were unified under a single "components" object. This validator only supports OpenAPI 3.x specs.

An OpenAPI 3.x document must have three top-level required fields: (1) "openapi" — a string like "3.0.3" or "3.1.0" indicating the specification version; (2) "info" — an object containing at minimum "title" (string) and "version" (string); and (3) "paths" — an object mapping URL paths to their operations. All other fields such as "servers", "components", "tags", and "security" are optional but recommended.

Yes. This validator accepts both YAML and JSON formats. Use the YAML/JSON toggle to hint which format your spec is in. The validator tries JSON.parse first for JSON-like input (starting with { or [), then falls back to the built-in YAML parser. Both formats are fully supported and produce identical validation results since they represent the same data structure.

The OpenAPI 3.x specification mandates that every operation object must include a "responses" field. This is because an API without defined responses provides no contract for clients — they cannot know what to expect. Each response code entry (e.g. "200", "404", "default") should include at minimum a "description" string explaining what that response means.

Errors (shown in red) indicate violations of the OpenAPI 3.x specification — your spec will not be parseable by conformant tools until these are fixed. Warnings (yellow) indicate practices that are technically allowed but strongly discouraged, such as operations without a summary or response objects without descriptions. Info messages (blue) are suggestions for improving spec quality, such as adding server URLs or schema descriptions, but are entirely optional.