OpenAPI Spec Validator

Paste your OpenAPI v3 spec (JSON or YAML) to check whether the required root fields (openapi, info, paths) are present and whether every path defines at least one HTTP method.

OpenAPI Spec (JSON or YAML) — drag a file in, or

How to use it

Paste an OpenAPI 3.x JSON or supported YAML document, open a local file, or load the example.
Select Validate or press Ctrl/⌘ + Enter.
Correct missing root fields and paths without an HTTP operation.
Send a parsed document to JSON Tree Viewer when you need to inspect its structure.

OpenAPI validation example

openapi: 3.0.3
info:
  title: Users API
  version: 1.0.0
paths:
  /users:
    get:
      summary: List users

This document passes the structural preflight because it declares an OpenAPI 3.x version, supplies info.title and info.version, contains a non-empty paths object, and defines a recognized HTTP method for /users.

Checks performed by this tool

The root openapi value exists and begins with version 3.
info is an object containing both title and version.
paths exists, is an object, and is not empty.
Every path contains at least one of get, post, put, delete, patch, options, head, or trace.

These checks catch common scaffolding mistakes quickly. They are especially useful before sharing a draft, committing a generated file, or investigating why documentation tooling does not show an endpoint.

What is not validated

This is deliberately not a complete implementation of the OpenAPI specification. It does not resolve $ref targets, validate parameter locations, require operation responses, check media types, evaluate security schemes, or apply every Schema Object rule. A passing result means the required outer structure looks usable, not that every client generator and gateway will accept the contract.

The bundled YAML reader supports mappings, lists, and basic scalar values. Anchors, aliases, multi-document input, flow style, tags, and other advanced YAML features may require conversion with a complete parser before this preflight can inspect the document.

Common OpenAPI errors

openapi is missing or not 3.x: Swagger 2 documents use a different root field and are not accepted here.
info.title or info.version is missing: both strings are required metadata for the API definition.
paths is empty: add at least one path item before treating the document as an API contract.
Path has no valid method: the path may contain parameters or extensions but still needs an HTTP operation.
Parse error: fix JSON syntax or simplify unsupported YAML features first.

Validation runs entirely in the browser. The pasted API contract is not uploaded to Cryonel. For ongoing detection of breaking contract changes rather than a one-time structural check, see API Guard.

Frequently Asked Questions

Are YAML specs supported?

Yes — if JSON parsing fails, the tool automatically falls back to a lightweight YAML parser (see the limitations noted on the JSON ⇄ YAML page).

Does it support OpenAPI 2.0 (Swagger)?

No, this tool only checks the required field structure of OpenAPI 3.x.

Is this a complete OpenAPI schema validator?

No. It is a fast structural preflight for the version, info, paths, and HTTP methods. It does not resolve references or validate every operation, parameter, response, security scheme, or Schema Object rule.