01
JSON and YAML support
Validate either common OpenAPI serialization without converting it first.
Start typing to search 227 tools.
Validator
Ready
OpenAPI Validator
Validate the required structure of OpenAPI 3.0 and 3.1 documents supplied as JSON or YAML.
JSON and YAML input OpenAPI 3.0.x and 3.1.x version check Required info and paths validation Path operation and response checks
Private browser processing. Your input is processed on this device and is not sent to the Trexmi server.
INPUT OpenAPI JSON or YAML *
Paste the source value for this specific transformation. Example: openapi: 3.1.0
info:
title: Trexmi API
version: 1.0.0
paths: {}
Reading file…
OpenAPI validation
OpenAPI validation ready to review and copy.
About the tool
What OpenAPI Validator does
OpenAPI Validator parses an OpenAPI document supplied as JSON or YAML and checks essential OpenAPI 3.0.x or 3.1.x structure. It reports errors with document paths so missing or malformed sections are easier to locate.
The check covers the openapi version, required info.title and info.version values, the paths object, HTTP operation names, and required non-empty responses. It also checks the basic container type of components, security, tags, and externalDocs when present.
This is a focused structural validator, not a complete implementation of every OpenAPI rule. It does not resolve external references, validate every Schema Object keyword, or prove that an API server matches the contract.
How to use
- Paste the complete document. JSON input may begin with
{; otherwise the tool parses the source as YAML. - Run validation. The result identifies the version and lists structural errors.
- Follow each path. Use entries such as
$.info.titleor$.paths./users.get.responsesto find the source location. - Correct the contract. Re-run until the focused structural check passes.
- Perform deeper validation. Test references, schemas, examples, security, client generation, and server behavior with production tooling.
Built for the task
Why use OpenAPI Validator?
Focused controls, predictable output, and a workflow designed around this exact transformation.
02
Essential structure checks
Catch missing version, info, paths, operations, and response objects.
03
Actionable error paths
Each issue includes a document path and concise message for faster correction.
04
Defined validation scope
The page clearly separates focused structural checks from full specification conformance.
Useful answers
Questions about OpenAPI Validator
Practical details about input, output, privacy, limits, and the best way to use this tool.
01 Which OpenAPI versions are supported?
The validator accepts version strings for OpenAPI 3.0.x and 3.1.x.
02 Can I validate YAML and JSON?
Yes. Input beginning with a JSON object or array marker is parsed as JSON; other input is parsed as YAML.
03 Does it validate Swagger 2.0?
No. Swagger 2.0 uses a different top-level version field and is outside the current validator scope.
04 Does it resolve $ref references?
No. Internal and external reference resolution requires a fuller OpenAPI validation tool.
05 Are all Schema Object keywords checked?
No. The tool focuses on essential document and operation structure rather than full JSON Schema or OpenAPI conformance.
06 Why must path keys begin with a slash?
OpenAPI path template keys represent relative endpoint paths and normally begin with /.
07 Does a valid result prove the API works?
No. It does not call the API or compare live responses with the contract.
08 Should production secrets be included?
No. Replace tokens, private server addresses, credentials, and sensitive examples with safe placeholders.
Examples
Minimal valid document
An empty paths object is structurally accepted by this focused check.
Input
openapi: 3.1.0
info:
title: Example API
version: 1.0.0
paths: {}
Output
valid: true · version: 3.1.0 · error_count: 0
Missing info version
The error path points directly to the missing required field.
Input
openapi: 3.0.3
info:
title: Example API
paths: {}
Output
$.info.version: info.version is required
Operation without responses
Every checked HTTP operation needs a responses object.
Input
openapi: 3.1.0
info: {title: Example, version: 1.0.0}
paths:
/users:
get: {}
Output
$.paths./users.get.responses: Operation responses object is required
OpenAPI JSON and YAML input
OpenAPI documents can be serialized as JSON or YAML. The data model is the same, but YAML indentation, quoting, and scalar rules can introduce parse errors before OpenAPI validation begins. Paste the complete document and preserve its original nesting.
If parsing fails, first validate the serialization. A YAML syntax error and an OpenAPI structure error are different problems. Use a format-specific validator to isolate the first layer.
What this OpenAPI Validator checks
The root must be an object. The openapi field must identify a supported 3.0.x or 3.1.x release. The info object must contain non-empty title and version strings, while paths must be an object.
Within paths, route keys must begin with a slash. Recognized HTTP operations include GET, PUT, POST, DELETE, OPTIONS, HEAD, PATCH, and TRACE. Every operation must be an object with a non-empty responses object. Extension keys beginning with x- are ignored, as are supported path-item fields such as parameters and servers.
Focused structural validation is not full conformance
A passing result confirms only the checks documented on this page. It does not dereference $ref, verify parameter uniqueness, compare path variables with parameters, validate media-type schemas, check discriminator behavior, or enforce every OpenAPI and JSON Schema constraint.
Use a mature OpenAPI linter or validator in CI, then test generated clients, documentation, mock servers, and the real implementation. Structural validation is an early filter, not the final release gate.
How to read validation error paths
Errors use a JSON-style path beginning with $. For example, $.info.version identifies the version inside the info object. A path containing a route and method points to a specific operation. Fix the source at that location and run the validator again.
When many downstream errors appear, repair parse errors and missing top-level objects first. One malformed container can cause several later checks to fail.
OpenAPI contract release checklist
- Parse the complete JSON or YAML source.
- Validate the exact OpenAPI version used by the project.
- Resolve all internal and external references.
- Lint operations, parameters, schemas, examples, and security schemes.
- Run contract tests against staging responses.
- Generate at least one intended client or documentation build.
- Remove secrets and private examples before publishing.
Related Trexmi tools
Check schema rules with JSON Schema Validator, isolate YAML syntax with YAML Validator, or normalize JSON with JSON Formatter.
When an API example is supplied as cURL, turn it into application code with cURL to Go net/http or cURL to PHP cURL.
Authoritative reference
Consult the official OpenAPI 3.1.2 Specification for complete normative requirements. OpenAPI 3.2 uses a newer specification and is outside this tool version check.