OpenAPI Viewer

Extract and view API endpoints from an OpenAPI / Swagger JSON file.

See every endpoint of an API definition in one table

OpenAPI and Swagger files can run to thousands of lines, most of it schemas and response descriptions. When all you want to know is what the API exposes, that is a lot to scroll through. The OpenAPI Viewer reads the paths section of a JSON definition and lists each operation in a compact table with its HTTP method, route and one-line summary.

Reading a definition

Paste the full JSON of your OpenAPI 3 or Swagger 2 document into Input Data. The Sample button fills in a two-endpoint Demo API if you just want to see the layout.
Click Process / Generate.
The summary row shows the API Title taken from the info block and the total number of endpoints found. Below it, a table has three columns: Method, Endpoint Path and Summary.
Use Copy or Download to save the table text, or Clear to load another file.

What you will see

Every path is expanded into one row per method beneath it. Method names are colored so that they are easy to scan: POST in green, PUT in amber, DELETE in red, and everything else, including GET and PATCH, in blue. The summary column shows the summary field of each operation, and stays blank if the definition does not have one.

Practical uses

Getting a quick inventory of an unfamiliar third-party API before deciding whether to integrate it.
Auditing your own spec to spot operations missing a summary.
Counting endpoints when scoping a client SDK, a test plan or a migration.
Pasting a readable route list into a design document or ticket.

Limitations to expect

Only JSON is accepted, so a YAML file must be converted first. The input must contain a top-level paths object, otherwise the tool tells you none was found, and malformed JSON gets an invalid-format message. The viewer does not resolve references, and it does not show parameters, request bodies, response codes, schemas, tags or authentication settings. Because it treats every key under a path as an operation, path-level entries such as a shared parameters list may appear as an extra row with an uppercase label and no summary, and they add to the endpoint count. Webhooks and callbacks are not listed. Treat the count as a quick indication rather than an exact audit, and open the source file in a full documentation renderer when you need request and response details.

Related Tools

Frequently Asked Questions

Can I paste a YAML OpenAPI file?

No. The viewer parses JSON only, so YAML input will produce an invalid-format error. Convert the YAML to JSON first with any converter, then paste the result. Both Swagger 2.0 and OpenAPI 3.x JSON work as long as there is a paths object.

What columns does the results table show?

Three: the HTTP method, the endpoint path and the operation summary. It also shows the API title from the info section and the total number of endpoints in the summary row above the table.

Why do I see a row called PARAMETERS?

Every key under a path is treated as an operation. If your spec defines shared parameters or a summary at the path level, those keys appear as extra rows with blank summaries and count toward the total. You can ignore those rows.

Does it show request bodies, response schemas or auth details?

No. It lists only method, path and summary. For parameters, schemas, response codes and security schemes, use the source specification or a full Swagger-style documentation renderer alongside this quick overview.

What happens if there is no paths section?

The tool shows an error saying no 'paths' were found in the OpenAPI definition. This usually means you pasted only a fragment, such as the components section, or a definition where paths sit under a different structure.