Does this validate against the full OpenAPI JSON Schema meta-schema?

No. It runs a focused set of structural checks (required top-level fields, valid HTTP method keys, non-empty responses, path parameters that are actually declared, duplicate operationIds) rather than a full meta-schema validation, so it catches the mistakes that most commonly break tooling without needing to bundle the entire OpenAPI schema.

Does it support both JSON and YAML input?

Yes. The input is parsed as JSON first, and if that fails, as YAML, so you can paste either format without selecting one first.

What happens if I paste a Swagger 2.0 document here instead?

It's detected and rejected with a message pointing you to the Swagger Validator, since a document with a "swagger" field instead of "openapi" needs the Swagger-specific checks instead.

What's the difference between an error and a warning here?

Errors are things that break codegen, validation, or routing outright, like a missing responses object or an undeclared path parameter. Warnings flag things that are technically valid but worth fixing, like a missing operationId or an unrecognized version string.

OpenAPI Validator - Check an OpenAPI 3.x Spec for Common Errors

Overview

Introduction

A hand-edited OpenAPI document is easy to get subtly wrong: a path parameter with no matching declaration, an operation with no responses object, two operations sharing an operationId.

This tool checks for exactly those mistakes and reports each one with its location in the spec, entirely in your browser.

What Is OpenAPI Validator?

A structural validator for OpenAPI 3.x documents, accepting either JSON or YAML input.

It's part of this site's API Tools collection and runs entirely client-side. For Swagger 2.0 documents, use the separate Swagger Validator instead.

How OpenAPI Validator Works

The document is parsed and checked for required top-level fields (an openapi version field, info.title, info.version, a paths object), then every operation under every path is checked for a valid HTTP method key, a non-empty responses object, and path parameters that actually have a matching parameter definition.

Every operationId encountered is tracked so a duplicate can be reported against both locations that use it.

When To Use OpenAPI Validator

Use it after hand-editing an OpenAPI document, before feeding it to a code generator or API gateway that will fail cryptically on a structural mistake.

It's also useful for spot-checking a spec pulled from a third party before trusting it in your own tooling.

Often used alongside Swagger Validator, Postman to OpenAPI Converter and OpenAPI to Postman Converter.

Features

Advantages

Catches the specific mistakes that most commonly break codegen and routing tools, not just generic JSON/YAML syntax errors.
Reports each issue's location in the document (as a dotted path) alongside a plain-language explanation.

Limitations

Doesn't perform full JSON Schema validation against the OpenAPI meta-schema, so some deeper structural mistakes may go unreported.
Doesn't resolve $ref pointers, so an issue hidden behind a reference to another file or section won't be checked.

Examples

An undeclared path parameter

Input

paths: {"/users/{id}": {get: {responses: {"200": {description: "ok"}}}}}

Output

Error at paths./users/{id}.get: Path parameter "{id}" has no matching "in: path" parameter definition.

The path template declares {id}, but no parameters array anywhere on that operation or path item declares an in: path parameter named id.

A missing responses object

Input

paths: {"/ping": {get: {operationId: "ping"}}}

Output

Error at paths./ping.get.responses: Missing required, non-empty "responses" object.

Every operation must declare at least one response, since tooling relies on it to know what a successful (or error) call returns.

Best Practices & Notes

Best Practices

Run this after any manual edit to a spec, since path-parameter and responses mistakes are easy to introduce silently.
Add an operationId to every operation, even though it's only a warning here; a missing one causes real problems in most code generators.
Follow up with a full JSON Schema-based validator for critical, publicly-shared specs, since this tool intentionally focuses on the highest-impact structural mistakes only.

Developer Notes

Path parameters are detected with a `{([^}]+)}` match against each path template segment, then cross-checked against the union of path-item-level and operation-level `parameters` arrays filtered to `in: "path"`, which mirrors how OpenAPI actually resolves parameter inheritance between a path item and its operations. The check logic is shared with the Swagger Validator through a common core parameterized by which version field to expect.

OpenAPI Validator Use Cases

Validating a hand-written or hand-edited OpenAPI spec before running it through a code generator
Checking a third-party API's published spec for the kind of mistakes that break client generation
Finding duplicate operationIds introduced by copy-pasting an operation and forgetting to rename it

Common Mistakes

Assuming a spec that passes here is fully valid; it targets common, high-impact mistakes, not full meta-schema conformance.
Declaring a path parameter only in a $ref-referenced shared parameters file, which this validator doesn't resolve.

Tips

Fix errors before warnings; warnings like a missing operationId won't break tooling the way an undeclared path parameter will.

OpenAPI Validator