OpenAPI Validator
Validate OpenAPI specs (OAS 3.0/3.1) in YAML/JSON in your browser. Classifies issues by severity with an endpoint tree view. No external data transfer.
Last updated:
How to Use
Expand how to useCollapse how to use
- 1
Enter OpenAPI Spec
Paste your OpenAPI specification in YAML/JSON format into the text area, or upload a file. Sample presets are also available.
- 2
Review Validation Results
Validation runs in real-time as you type. Errors, warnings, and info are displayed by severity level.
- 3
Explore Endpoints
Defined API endpoints are displayed in a tree view grouped by tags. View methods, paths, and summaries at a glance.
OpenAPI Specification
Validation Result
Enter an OpenAPI specification to validate
About OpenAPI Validator
OpenAPI Validator checks your OAS 3.0/3.1 specs in YAML or JSON for structural errors, missing required fields, and common schema problems. Catch missing operationId, malformed path parameters, or duplicate response codes before they break code generation in tools like openapi-generator or Speakeasy, fail a spectral lint check in CI, or confuse Swagger UI. Issues are classified by severity (error/warning/info) and linked to the exact spec path, and all defined endpoints are rendered in a tag-grouped tree view for a quick API surface sanity check.
Key Features
- Supports OpenAPI 3.0/3.1 in YAML/JSON (auto-detection)
- Structural validation (required fields, path format, HTTP methods)
- Endpoint tree view grouped by tags
- Issues classified as error, warning, or info
- File upload support (.yaml/.yml/.json)
- Client-side validation, no external data transfer
Use Cases
- Validate an OAS 3.1 spec before running openapi-generator or Speakeasy to avoid code generation failures from malformed schemas
- Catch missing operationId or duplicate path parameters that break Swagger UI rendering before committing
- Run a quick structural sanity check on a third-party API spec (e.g., a vendor's OpenAPI file) before importing it into Postman or Insomnia
- Use as a pre-commit gate to surface spec errors locally before a spectral lint step in GitHub Actions CI
- Get an endpoint tree overview when onboarding to a new service — quickly see all routes, HTTP methods, and operation summaries without reading raw YAML
FAQ
Is Swagger 2.0 supported?
Currently only OpenAPI 3.0/3.1 is supported. If Swagger 2.0 input is detected, an error message will notify you.
Is my data sent to external servers?
No. Validation runs locally in your browser. API spec files containing internal route structures, authentication schemes, or proprietary endpoint designs are never transmitted.
Can $ref references be resolved?
Currently only $ref format checking is performed — external file and URL reference resolution is not supported. For full $ref resolution across bundled specs, use a CLI tool like swagger-cli bundle or Redocly CLI before pasting the resolved spec here.
How are custom extensions (x- prefixed keys) handled?
Extension fields with the x- prefix are allowed without warnings, as per the OpenAPI specification. This includes common vendor extensions like x-amazon-apigateway-integration (AWS API Gateway), x-google-backend (GCP), and documentation extensions used by Redoc or Stoplight.
How does this compare to running spectral lint in CI?
This tool performs structural validation (required fields, path formats, HTTP methods, operationId uniqueness) and is best for quick manual checks during development. Spectral with a custom ruleset in GitHub Actions CI covers a broader and customizable set of style and best-practice rules. Use this tool to catch obvious errors locally before spectral runs in your pipeline.