OpenAPI / Swagger Spec Viewer
Paste or fetch an OpenAPI 3.x or Swagger 2.0 spec — browse endpoints, schemas, and parameters with method-colour badges.
How to Use the OpenAPI Spec Viewer
- Paste tab — paste your OpenAPI JSON or YAML spec and click Parse & View. The tool auto-detects format.
- URL tab — enter a public URL that returns an OpenAPI spec. The API must support CORS headers.
- Browse endpoints — each endpoint shows as a collapsible card with method badge, path, summary, parameters, request body, and responses.
- Filter — use the search bar or method filter buttons to focus on specific endpoints.
- Analyze — switch to Analyze mode for a quality audit: endpoint counts, schema list, missing descriptions.
What Is OpenAPI?
OpenAPI (formerly known as Swagger) is the industry-standard format for describing REST APIs. An OpenAPI spec is a machine-readable document — in JSON or YAML — that documents every endpoint your API exposes: the HTTP method, path, path and query parameters, request body schema, response codes, response body schemas, and authentication requirements. It is used by API gateway tools, SDK generators, documentation sites (like Swagger UI and Redoc), and testing frameworks. Teams that write an OpenAPI spec first (design-first approach) can generate server stubs, client SDKs, and mock servers before writing a single line of application code.
OpenAPI 2.0 vs 3.x
OpenAPI 2.0 (Swagger 2.0) is widely deployed but has structural limitations: it uses host and basePath instead of servers, puts request bodies in the parameters array, and stores schemas under definitions. OpenAPI 3.0 restructured these: servers is a proper array of server objects, request bodies are a separate requestBody field, and reusable objects live under components. OpenAPI 3.1 aligns fully with JSON Schema Draft 2020-12, enabling features like if/then/else, unevaluatedProperties, and $defs. This viewer handles both 2.0 and 3.x specs.
Reading Endpoint Details
Each endpoint card shows: the HTTP method badge (GET in green, POST in blue, PUT in orange/amber, PATCH in purple, DELETE in red), the full path, a summary (short description), and the operation ID (used for code generation). Click to expand an endpoint and see all path/query parameters (name, location, required status, type, description), the request body schema and content type, and all defined responses with their status codes and descriptions. Use this viewer alongside the API Mock Generator to generate test data that matches your schemas.
API Design Quality with Analyze Mode
The Analyze mode audits your API spec for completeness and quality. Good API design requires that every endpoint has a summary and description, every parameter is documented with a type and description, every response code is explicitly defined (not just 200), and reusable schemas are in components/schemas rather than inlined in every endpoint. Automated tools like Spectral, Vacuum, and Redocly CLI can lint your OpenAPI spec against these rules. Use the Analyze results here as a quick pre-flight check before running a full linter. For building your API's mock data layer, see our Mock Generator, and use the GraphQL Query Builder if your API is GraphQL-based.