OpenAPI / Swagger Validator
DataValidate an OpenAPI 3.x or Swagger 2.0 specification for required fields and structural correctness. Paste JSON or YAML. Free, client-side, no data uploaded.
What is a OpenAPI?
The OpenAPI / Swagger Validator checks whether an API specification document contains all required structural fields and correctly identifies its version — OpenAPI 3.x or Swagger 2.0. Paste your spec in JSON or YAML format and the tool reports: the detected spec version, total endpoint count, and the specific required fields that are missing, if any.
OpenAPI (formerly Swagger) is the de-facto standard for describing REST APIs. A valid spec is the foundation of every downstream tool in the API lifecycle — documentation generators like Redoc and Swagger UI, mock servers, API gateway configurations, SDK generators, and contract testing frameworks all parse the spec before doing anything else. An invalid spec — missing info.title, no paths, or an unrecognised root key — breaks these tools silently or with cryptic errors far removed from the actual problem in the spec file.
This validator performs a structural check: it confirms the required root-level fields are present and reports the endpoint count. It does not resolve $ref pointers, validate individual schema definitions, or check whether response body shapes match declared schemas. For full semantic linting, the scope disclaimer is explicit: use Redocly CLI or the Swagger Editor for production-ready spec validation. For pure syntax validation of YAML specs, the YAML Validator is the complementary tool.
Validation runs entirely in your browser. Your spec content is never transmitted to a server or stored anywhere — safe for pre-release or internal API definitions.
How to use this OpenAPI calculator
- Paste your OpenAPI 3.x or Swagger 2.0 specification into the spec input area. The default example shows a minimal valid OpenAPI 3.0.3 document in YAML format — you can paste JSON or YAML.
- The tool processes your input automatically. No submit button is needed.
- Check the Valid or Invalid badge at the top of the result panel.
- If Valid: read the details — confirm the detected spec version is correct and review the endpoint count to ensure all paths are being read as expected.
- If Invalid: read the details list of missing fields. Each missing field is listed by its full dotted path (e.g.,
info.version) so you can locate it directly in your spec. - Fix the reported fields in your spec, paste the corrected version back, and re-validate until the Valid badge appears.
- Once the structural check passes, run a full linter (Redocly CLI or Swagger Editor) for deeper schema and reference validation before publishing or importing the spec.
Formula & Methodology
### Version Auto-Detection The tool reads the root of the parsed document for two keys: -openapikey present → classified as OpenAPI 3.x. The value (e.g.,"3.0.3","3.1.0") is reported as the spec version. -swaggerkey present → classified as Swagger 2.0. The value (e.g.,"2.0") is reported as the spec version. - Neither key present → reported as unrecognised format. ### Required Fields by Spec Version OpenAPI 3.x required fields: | Field | Location | Rule | |---|---|---| |openapi| Root | Must be present; value must start with3.| |info.title|infoobject | Non-empty string | |info.version|infoobject | Non-empty string | |paths| Root | Must be present and contain at least one path with at least one HTTP method operation | Swagger 2.0 required fields: | Field | Location | Rule | |---|---|---| |swagger| Root | Must equal"2.0"| |info.title|infoobject | Non-empty string | |info.version|infoobject | Non-empty string | |paths| Root | Must be present and contain at least one path with at least one HTTP method operation | ### JSON vs YAML Handling JSON input: the spec is fully parsed usingJSON.parse(). All required field lookups traverse the parsed object tree precisely. YAML input: the tool performs structural key extraction using heuristic pattern matching on the raw YAML text. Top-level keys (e.g.,openapi:,info:,paths:) and first-level nested keys underinfo:(e.g.,title:,version:) are identified by scanning for key patterns at the expected indentation levels. This approach correctly handles standard YAML formatting. Deeply nested$refpointers, custom anchors, and non-standard indentation may not be fully resolved — use the YAML Validator first if your spec has unusual formatting. ### Endpoint Count Calculation The tool counts HTTP method operations by looking for the standard HTTP method keys (get,post,put,patch,delete,head,options,trace) under each path item inpaths. Each method key found under a path counts as one endpoint. This matches how Postman, Stoplight, and Redocly count API operations. Valid minimal OpenAPI 3.x example (JSON):json { "openapi": "3.0.3", "info": { "title": "My API", "version": "1.0.0" }, "paths": { "/users": { "get": { "summary": "List users", "responses": { "200": { "description": "OK" } } } } } }Result: Valid — OpenAPI 3.0.3 — 1 endpoint detected. Invalid example (missinginfo.version):yaml openapi: "3.0.3" info: title: My API paths: /users: get: summary: List users responses: "200": description: OKResult: Invalid — missing field:info.version.
Frequently Asked Questions
OpenAPI is a specification standard for describing RESTful HTTP APIs in a machine-readable format — typically a JSON or YAML document that lists every endpoint, its parameters, request bodies, response schemas, and authentication requirements. It was originally called the Swagger Specification before being donated to the OpenAPI Initiative in 2016. Tools across the API lifecycle — documentation generators, mock servers, code generators, and API gateways — all consume the OpenAPI format, making a valid spec the foundation for a well-tooled API workflow.
Swagger 2.0 (published in 2014) and OpenAPI 3.x (introduced in 2017) share the same goals but have different required fields and structural conventions. Swagger 2.0 documents start with `swagger: "2.0"` and require `info`, `paths`, and `host` at the root. OpenAPI 3.x documents start with `openapi: "3.0.x"` (or `3.1.x`) and require `info` and `paths`, replacing `host`/`basePath`/`schemes` with a `servers` array and restructuring request body and response schema definitions under `components`. The two formats are not directly interchangeable — migration tools like `swagger2openapi` exist to convert between them.
This validator performs a structural check on your spec: it detects whether the document is OpenAPI 3.x or Swagger 2.0 by reading the `openapi` or `swagger` root key, then confirms that all required root-level fields are present (`info.title`, `info.version`, and at least one HTTP method under `paths`). It reports the spec version, total endpoint count, and any missing required fields. It does not resolve `$ref` pointers, validate per-schema data types, or check response body shapes — for full semantic linting, use Redocly CLI or the Swagger Editor.
No. `$ref` resolution — following references like `$ref: '#/components/schemas/User'` across the document or to external files — is outside the scope of this tool. A spec with broken `$ref` targets will still show as valid here if all required root fields are present. For full reference resolution and deep schema validation, use the Redocly CLI (`redocly lint`) or the Swagger Editor at editor.swagger.io, both of which resolve the full reference graph.
Yes. Paste either a JSON or YAML spec and the tool detects the format automatically. For JSON input, the spec is fully parsed and all required fields are checked precisely. For YAML input, the tool performs structural key extraction — reading the top-level keys and nested field names using a heuristic approach — which is sufficient to validate the presence of required fields. Full YAML parsing (with `$ref` resolution) requires a server-side library; for that level of checking use the Redocly CLI or the [YAML Validator](/yaml-validator/) for pure syntax validation.
The tool reads the root key of the document. If the root contains an `openapi` key (e.g., `openapi: "3.0.3"`), it is treated as an OpenAPI 3.x document. If it contains a `swagger` key (e.g., `swagger: "2.0"`), it is treated as a Swagger 2.0 document. If neither key is present, the tool reports an unrecognised format. The value of the key also determines the version string shown in the output — `3.0.3`, `2.0`, etc.
No. Validation runs entirely in your browser. Your spec content is never transmitted to any server, stored in a database, or shared with any third party. This makes the tool safe to use with internal or pre-release API specifications that you would not want exposed outside your organisation. The same client-side approach applies to the [JSON Validator](/json-validator/) and [YAML Validator](/yaml-validator/) on this site.
Add a `version` field inside the `info` block of your spec. In YAML: place `version: "1.0.0"` as a sibling of `title` under `info`. In JSON: add `"version": "1.0.0"` alongside `"title"` in the `"info"` object. The version string must be a quoted string — it does not need to follow semantic versioning, though a value like `"1.0.0"` is conventional. After adding the field, paste the corrected spec back and re-validate.
The endpoint count represents the total number of HTTP operation objects found under `paths`. Each path item (e.g., `/users`) can contain multiple operations for different HTTP methods (`get`, `post`, `put`, `patch`, `delete`, `head`, `options`, `trace`). Each operation counts as one endpoint. A spec with three paths where one path has a `get` and `post` operation would report five endpoints. This matches how tools like Postman and Stoplight count operations.
The OpenAPI Initiative publishes a JSON Schema for each OpenAPI version that describes every valid field, its type, and constraints. You can use the [JSON Schema Validator](/json-schema-validator/) to check your spec against the official OpenAPI 3.0 or OpenAPI 3.1 meta-schema — paste your spec as the document and the published JSON Schema as the schema. For built-in automated linting of the full semantic rules, Redocly CLI (`npm install -g @redocly/cli && redocly lint openapi.yaml`) is the recommended open-source tool.
Yes. OpenAPI 3.1 documents have an `openapi` key starting with `3.1` (e.g., `openapi: "3.1.0"`). The tool detects this as an OpenAPI 3.x document and applies the same required-field checks as for 3.0.x: `info.title`, `info.version`, and at least one operation under `paths`. OpenAPI 3.1 aligns more closely with JSON Schema draft 2020-12 for schema definitions, which may affect schema-level validation — but this tool checks structural required fields only, so 3.1 input is handled without issue.
Start with this tool to confirm the required fields are present and the spec version is detected correctly. Then run Redocly CLI or Swagger Editor for full semantic linting that resolves `$ref` pointers and validates schema constraints. Use the [JSON Schema Validator](/json-schema-validator/) if you need to check against a specific OpenAPI meta-schema version. Finally, generate documentation (via Redoc or Swagger UI) and review the rendered output to catch description copy and example quality issues that linters do not surface.
Also known as