DevBolt
Processed in your browser. Your data never leaves your device.

How do I validate an OpenAPI or Swagger spec online?

Paste your OpenAPI 3.x or Swagger 2.0 spec in JSON or YAML format and click Validate. The tool checks structure, paths, operations, parameters, schemas, security definitions, $ref resolution, and best practices. Issues are grouped by severity with specific fix guidance. Everything runs in your browser.

Validate OpenAPI 3.0 spec
Input
openapi: "3.0.3"
info:
  title: Users API
  version: "1.0"
paths:
  /users:
    get:
      summary: List users
      responses:
        "200":
          description: OK
Output
✓ Valid OpenAPI 3.0.3
Paths: 1
Operations: 1 (GET /users)
Schemas: 0
No errors or warnings

OpenAPI / Swagger Validator

Validate OpenAPI 3.x and Swagger 2.0 specifications. Checks structure, paths, operations, parameters, schemas, security, and best practices.

Tips & Best Practices

Pro Tip

Validate your spec in CI to prevent drift from implementation

Add OpenAPI validation to your CI pipeline. Every PR that changes routes should also update the spec. Stale specs mislead consumers, break code generation, and cause integration failures. Tools like spectral or redocly lint can enforce rules beyond basic schema validity.

Common Pitfall

A valid spec doesn't mean a usable API

Validation checks structure (valid JSON/YAML, required fields, correct $ref targets) but not quality. An API with 50 endpoints all named /do-thing-1 through /do-thing-50, no descriptions, and no examples passes validation but is unusable. Add descriptions, examples, and consistent naming.

Real-World Example

Validate before publishing to API marketplaces or gateways

API gateways (Kong, Apigee), documentation tools (Redoc, Swagger UI), and marketplaces (RapidAPI) all consume OpenAPI specs. An invalid spec fails silently — routes don't appear, parameters are missing, or types are wrong. Always validate before publishing to catch $ref errors and missing schemas.

Security Note

Define security schemes for every endpoint

OpenAPI specs should declare security schemes (Bearer token, API key, OAuth2) and apply them to each operation. Endpoints without a security requirement in the spec might accidentally be deployed without authentication. Use the validator to verify every endpoint has appropriate security defined.

Frequently Asked Questions

How do I validate an OpenAPI specification?
Paste your OpenAPI 3.x or Swagger 2.0 spec in JSON or YAML format. The validator parses it and checks against the official specification, reporting structural errors, missing required fields, invalid references, and schema issues. It verifies paths, operations, parameters, request bodies, responses, and security definitions. Broken $ref references are flagged immediately. Results include the exact path of each issue. All validation runs client-side in your browser.
What is the difference between OpenAPI 3.0 and Swagger 2.0?
Swagger 2.0 uses swagger: 2.0, puts schemas under definitions, and uses in-body parameters. OpenAPI 3.0 uses openapi: 3.0.x, moves schemas to components/schemas, introduces a dedicated requestBody object, and adds support for multiple server URLs replacing host/basePath/schemes. OpenAPI 3.0 also adds content/mediaType patterns, callbacks, links, and cookie parameters. The validator auto-detects the version and applies appropriate rules.
What common OpenAPI errors does the validator catch?
The validator catches missing required fields (info, paths, openapi version), invalid path parameter syntax, path parameters declared but not defined, $ref pointers to non-existent schemas, type errors, invalid HTTP methods, and missing response descriptions. Best practice violations include missing operationId, unused schema definitions, and security schemes referenced but not defined. For Swagger 2.0, it also validates consumes/produces media types.

Related Inspect Tools