Home›Validators›Data›OpenAPI / Swagger Validator

OpenAPI / Swagger Validator

Data

Validate 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.

Reviewed by the thecalcu.com team · Last updated July 30, 2026

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.

Why Use an OpenAPI Validator?

A missing required field in an OpenAPI spec does not throw an error at authoring time, the YAML or JSON itself is syntactically valid. The failure surface is downstream: a documentation generator that renders an empty page, a code generator that crashes on a null info.title, or an API gateway import that rejects the spec without a helpful error message.

Common scenarios where this tool saves time:

  • Checking a hand-written spec for required fields before running redocly bundle or importing into API Gateway
  • Confirming the spec version is correctly declared (openapi: "3.0.3" vs swagger: "2.0") before passing it to a version-specific tool
  • Quickly counting total endpoints in a spec during API surface area reviews
  • Verifying a spec exported from Postman or Stoplight has all required fields before handing it to another team
  • Catching a broken YAML paste (spec pasted without proper indentation) before it causes a confusing downstream failure

The structural check here is fast and client-side, no toolchain required, no CLI to install, no account needed.

Who Should Use This Validator?

API developers and architects writing or reviewing OpenAPI specs by hand, validate required fields and version detection instantly without leaving the browser.

Backend engineers integrating with API gateways (AWS API Gateway, Kong, Azure API Management) that import OpenAPI specs, confirm the spec is well-formed before an import that fails mid-way through and leaves gateway configuration in a partial state.

DevOps and platform engineers building CI/CD pipelines that generate or bundle OpenAPI specs, add a quick structural check before the generated spec is consumed by documentation or code generation stages.

Technical writers and developer advocates maintaining public API reference documentation, catch missing info.title or info.version values that would produce malformed documentation headers.

QA engineers and contract testers setting up consumer-driven contract tests, confirm the spec has the required structure before configuring tools like Pact or Dredd.

For full semantic linting with $ref resolution and schema-level validation, use Redocly CLI or the Swagger Editor alongside this tool. For validating the raw JSON or YAML syntax before working with the spec structure, use the JSON Validator or YAML Validator.

What Insights Does the OpenAPI Validator Give You?

When the spec is valid, the output panel shows:

  • Spec version, the exact version string from the openapi or swagger key (e.g., 3.0.3 or 2.0)
  • Endpoint count, total number of HTTP operations across all paths (each get, post, put, etc. on each path counts as one endpoint)
  • Valid badge, confirming all required structural fields are present

When the spec is invalid, the output shows:

  • Invalid badge
  • Missing fields, the specific required fields that were not found (e.g., info.title, info.version, paths)
  • Format issue, if neither openapi nor swagger root keys are present, the tool reports an unrecognised format

Scope disclaimer: this is a structural required-field check, not a full semantic validator. The following are outside scope: $ref resolution, per-property schema type validation, response body shape checking, security scheme completeness, and OpenAPI extension (x-) field validation. For a complete linting report, use Redocly CLI (redocly lint) or the Swagger Editor at editor.swagger.io.

How to use this OpenAPI calculator

  1. 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.
  2. The tool processes your input automatically. No submit button is needed.
  3. Check the Valid or Invalid badge at the top of the result panel.
  4. 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.
  5. 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.
  6. Fix the reported fields in your spec, paste the corrected version back, and re-validate until the Valid badge appears.
  7. 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.
Show formula & methodology ↓Show less ↑

Formula & Methodology

### Version Auto-Detection

The tool reads the root of the parsed document for two keys:

- openapi key present → classified as OpenAPI 3.x. The value (e.g., "3.0.3", "3.1.0") is reported as the spec version.
- swagger key 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 with 3. |
| info.title | info object | Non-empty string |
| info.version | info object | 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 | info object | Non-empty string |
| info.version | info object | 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 using JSON.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 under info: (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 $ref pointers, 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 in paths. 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 (missing info.version):
yaml openapi: "3.0.3" info:   title: My API paths:   /users:     get:       summary: List users       responses:         "200":           description: OK 
Result: Invalid, missing field: info.version.

Frequently Asked Questions

What is OpenAPI?
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.
What is the difference between OpenAPI 3.x and Swagger 2.0?
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.
What does this validator actually check?
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.
Does this validator resolve $ref pointers?
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.
Does this validator support YAML input?
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.
How does the tool detect whether a spec is OpenAPI 3.x or Swagger 2.0?
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.
Is my API spec uploaded to a server when I use this tool?
Nothing is uploaded. Validation runs entirely in your browser, and 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.
How do I fix a 'missing info.version' error?
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.
How does the tool count endpoints?
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.
How do I validate my spec against a full JSON schema for OpenAPI?
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.
Can I use this tool with OpenAPI 3.1?
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.
What is the recommended workflow for validating an OpenAPI spec before publishing?
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
OpenAPI validatorSwagger validatorAPI spec validatorOpenAPI 3.0 checkSwagger YAML validator