OpenAPI 2 (Swagger) or 3?

Both. The viewer auto-detects the version. OpenAPI 3.x is the current standard; Swagger 2 is still widely used in older systems.

Read-only viewer. For live requests use Swagger UI hosted alongside the spec, or Postman/Insomnia importing the spec.

What's shown per endpoint?

Path, method, parameters, request body schema, response schemas, examples, descriptions. Everything from the spec rendered for reading.

Does it validate the spec?

Syntax yes — malformed OpenAPI shows parse errors. For semantic validation (correct schema shapes, no circular refs) use a dedicated linter like Spectral.

OpenAPI Viewer | DevTools Surf

DevTools Surf

Example: OpenAPI Viewer

A worked example, rendered from real sample data. Sign in to run the tool on your own input.

Input

{"openapi":"3.0.0","info":{"title":"Pet Store API","version":"1.0.0"},"paths":{"/pets":{"get":{"summary":"List all pets","parameters":[{"name":"limit","in":"query","schema":{"type":"integer"}}]},"post":{"summary":"Create a pet"}},"/pets/{petId}":{"get":{"summary":"Get a pet by ID"}}}}

Output

OpenAPI 3.0.0 — Pet Store API v1.0.0
3 endpoints across 1 tag · 0 schemas

default
  GET    /pets  — List all pets
  POST   /pets  — Create a pet
  GET    /pets/{petId}  — Get a pet by ID

Validation: 4 errors · 0 warnings · 4 notes
ERROR /pets  GET /pets declares no responses  [no-responses]
ERROR /pets  POST /pets declares no responses  [no-responses]
ERROR /pets/{petId}  GET /pets/{petId} uses {petId} but never declares it as a path parameter  [path-param-undeclared]
ERROR /pets/{petId}  GET /pets/{petId} declares no responses  [no-responses]
NOTE  servers  No servers declared — examples below use https://api.example.com  [no-servers]
NOTE  /pets  GET /pets has no operationId — generators need one  [operation-id]
NOTE  /pets  POST /pets has no operationId — generators need one  [operation-id]
NOTE  /pets/{petId}  GET /pets/{petId} has no operationId — generators need one  [operation-id]

About OpenAPI Viewer

OpenAPI Viewer preview - API / Config tool

Browse endpoints, schemas, and operations from an OpenAPI 3 spec. Part of the DevTools Surf developer suite. Browse more tools in the API / Config collection.

Use Cases

Explore third-party API endpoints during integration work
Review API schema changes in pull request reviews
Generate quick API documentation for internal microservices
Onboard new developers by visualizing the full API surface

Tips

Paste an OpenAPI 3 spec to browse all endpoints visually
Expand schemas to inspect request and response models
Filter operations by HTTP method or tag for quick navigation

Fun Facts

The OpenAPI Specification was originally called Swagger, created by Tony Tam in 2011; it was donated to the Linux Foundation's OpenAPI Initiative in 2015.
OpenAPI 3.0, released in July 2017, introduced components/schemas to replace definitions, and added support for callbacks and links.
Over 75% of REST APIs in enterprise use OpenAPI specs for documentation, according to SmartBear's 2023 State of APIs report.

FAQ

OpenAPI 2 (Swagger) or 3?: Both. The viewer auto-detects the version. OpenAPI 3.x is the current standard; Swagger 2 is still widely used in older systems.
Can I try requests?: Read-only viewer. For live requests use Swagger UI hosted alongside the spec, or Postman/Insomnia importing the spec.
What's shown per endpoint?: Path, method, parameters, request body schema, response schemas, examples, descriptions. Everything from the spec rendered for reading.
Does it validate the spec?: Syntax yes — malformed OpenAPI shows parse errors. For semantic validation (correct schema shapes, no circular refs) use a dedicated linter like Spectral.

Related API / Config Tools

REST Handler Swagger to Collection JSON package.json Analyzer Dockerfile Linter Kubernetes Manifest Validator Mock Server Config Generator API Request Builder GraphQL Explorer